From debbugs-submit-bounces@debbugs.gnu.org Fri May 09 18:49:45 2014 Received: (at submit) by debbugs.gnu.org; 9 May 2014 22:49:45 +0000 Received: from localhost ([127.0.0.1]:57399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Witbr-0008JF-Tt for submit@debbugs.gnu.org; Fri, 09 May 2014 18:49:45 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53936) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Witbp-0008J2-4j for submit@debbugs.gnu.org; Fri, 09 May 2014 18:49:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WitbZ-0006fk-Gx for submit@debbugs.gnu.org; Fri, 09 May 2014 18:49:35 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:45459) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WitbZ-0006fg-Do for submit@debbugs.gnu.org; Fri, 09 May 2014 18:49:25 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WitbR-0003SF-Lt for bug-gnu-emacs@gnu.org; Fri, 09 May 2014 18:49:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WitbK-0006eC-2w for bug-gnu-emacs@gnu.org; Fri, 09 May 2014 18:49:17 -0400 Received: from colin.muc.de ([193.149.48.1]:56704 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WitbJ-0006e4-Lp for bug-gnu-emacs@gnu.org; Fri, 09 May 2014 18:49:10 -0400 Received: (qmail 29276 invoked by uid 3782); 9 May 2014 22:49:05 -0000 Received: from acm.muc.de (pD9519D80.dip0.t-ipconnect.de [217.81.157.128]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 10 May 2014 00:49:04 +0200 Received: (qmail 4310 invoked by uid 1000); 9 May 2014 22:44:58 -0000 Date: Fri, 9 May 2014 22:44:58 +0000 To: bug-gnu-emacs@gnu.org Subject: Isearch doesn't work properly with Follow Mode. Message-ID: <20140509224458.GA4205@acm.acm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.3 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.3 (----) Hi, Emacs. Isearch doesn't work properly with Follow Mode. There follows a patch which is a first attempt to fix this. There are three main problems (there may be others): 1. Isearch commands stay in the same window when they ought to move across the entire screen. This is only actually a problem with lazy highlighting enabled. 2. Lazy highlighting is only applied to the current follow window, not all of them. 3. Scroll commands cannot scroll out of the current window. They ought to be able to scroll through any follow window. Most of the exercise was straightforward. The only trouble came where isearch-message (or isearch-message-function) was called from isearch-search. There are circumstances (see comments in the code) where calling isearch-message with follow-mode enabled can cause unwanted vertical scrolling. This happens when point is temporarily moved to isearch-other-end and then calling isearch-search. To get round this I refactored isearch-message out of isearch-search and inserted into the places just before isearch-search is called. Here's the patch: --- emacs/emacs.bzr/trunk/lisp/isearch.el 2014-03-03 11:50:56.000000000 +0000 +++ /home/acm/isearch.el 2014-05-09 22:10:29.000000000 +0000 @@ -166,6 +166,21 @@ :type 'boolean :group 'isearch) +(defvar isearch-windows nil + "List of windows active in the incremental search. +This is either the ordered list of active windows administered by +`follow-mode' or a list of the single window involved in the +search.") + +(defmacro isearch-windows-start (&optional wins) + "Get the start point of the windows involved in the isearch." + `(window-start (car ,(if wins wins 'isearch-windows)))) + +(defmacro isearch-windows-end (&optional wins update) + "Get the end point of the windows involved in the isearch." + `(window-end (car (last ,(if wins wins 'isearch-windows))) + ,@(if update `(,update)))) + (defvar isearch-mode-hook nil "Function(s) to call after starting up an incremental search.") @@ -184,6 +199,11 @@ "Function to call to display the search prompt. If nil, use function `isearch-message'.") +(defmacro isearch-call-message (&optional cqh ellip) + `(if isearch-message-function + (funcall isearch-message-function ,cqh ,ellip) + (isearch-message ,cqh ,ellip))) + (defvar isearch-wrap-function nil "Function to call to wrap the search when search is failed. If nil, move point to the beginning of the buffer for a forward search, @@ -203,7 +223,7 @@ `isearch-message-prefix' advice property to specify the prefix string displayed in the search message.") -;; Search ring. +;;; Search ring. (defvar search-ring nil "List of search string sequences.") @@ -860,6 +880,9 @@ isearch-regexp regexp isearch-word word isearch-op-fun op-fun + isearch-windows (if (and (boundp 'follow-mode) follow-mode) + (follow-all-followers) + (list (selected-window))) isearch-last-case-fold-search isearch-case-fold-search isearch-case-fold-search case-fold-search isearch-invisible search-invisible @@ -1254,13 +1277,6 @@ (unwind-protect (progn ,@body) - ;; Set point at the start (end) of old match if forward (backward), - ;; so after exiting minibuffer isearch resumes at the start (end) - ;; of this match and can find it again. - (if (and old-other-end (eq old-point (point)) - (eq isearch-forward isearch-new-forward)) - (goto-char old-other-end)) - ;; Always resume isearching by restarting it. (isearch-mode isearch-forward isearch-regexp @@ -1273,7 +1289,17 @@ isearch-message isearch-new-message isearch-forward isearch-new-forward isearch-word isearch-new-word - isearch-case-fold-search isearch-new-case-fold)) + isearch-case-fold-search isearch-new-case-fold) + + ;; Restore the minibuffer message before moving point. + (isearch-call-message nil t) + + ;; Set point at the start (end) of old match if forward (backward), + ;; so after exiting minibuffer isearch resumes at the start (end) + ;; of this match and can find it again. + (if (and old-other-end (eq old-point (point)) + (eq isearch-forward isearch-new-forward)) + (goto-char old-other-end))) ;; Empty isearch-string means use default. (when (= 0 (length isearch-string)) @@ -1417,16 +1443,20 @@ (isearch-ring-adjust1 nil)) ;; If already have what to search for, repeat it. (or isearch-success - (progn - ;; Set isearch-wrapped before calling isearch-wrap-function - (setq isearch-wrapped t) - (if isearch-wrap-function - (funcall isearch-wrap-function) - (goto-char (if isearch-forward (point-min) (point-max))))))) + ;; Set isearch-wrapped before calling isearch-wrap-function + (setq isearch-wrapped t))) ;; C-s in reverse or C-r in forward, change direction. (setq isearch-forward (not isearch-forward) isearch-success t)) + (isearch-call-message nil t) ; Call before moving point. + (if (and (eq isearch-forward (eq direction 'forward)) + (not (equal isearch-string "")) + (not isearch-success)) + (if isearch-wrap-function + (funcall isearch-wrap-function) + (goto-char (if isearch-forward (point-min) (point-max))))) + (setq isearch-barrier (point)) ; For subsequent \| if regexp. (if (equal isearch-string "") @@ -1867,6 +1897,7 @@ (length isearch-string)))) isearch-message (mapconcat 'isearch-text-char-description isearch-string ""))) + (isearch-call-message nil t) ; Do this before moving point. ;; Use the isearch-other-end as new starting point to be able ;; to find the remaining part of the search string again. ;; This is like what `isearch-search-and-update' does, @@ -2041,6 +2072,7 @@ (setq isearch-case-fold-search (isearch-no-upper-case-p isearch-string isearch-regexp)))) ;; Not regexp, not reverse, or no match at point. + (isearch-call-message nil t) ; Do this before moving point. (if (and isearch-other-end (not isearch-adjusted)) (goto-char (if isearch-forward isearch-other-end (min isearch-opoint @@ -2207,10 +2239,12 @@ together with as much of the search string as will fit; the symbol `above' if we need to scroll the text downwards; the symbol `below', if upwards." - (let ((w-start (window-start)) - (w-end (window-end nil t)) - (w-L1 (save-excursion (move-to-window-line 1) (point))) - (w-L-1 (save-excursion (move-to-window-line -1) (point))) + (let ((w-start (isearch-windows-start)) + (w-end (isearch-windows-end nil t)) + (w-L1 (with-selected-window (car isearch-windows) + (save-excursion (move-to-window-line 1) (point)))) + (w-L-1 (with-selected-window (car (last isearch-windows)) + (save-excursion (move-to-window-line -1) (point)))) start end) ; start and end of search string in buffer (if isearch-forward (setq end isearch-point start (or isearch-other-end isearch-point)) @@ -2236,14 +2270,18 @@ (setq start isearch-point end (or isearch-other-end isearch-point))) (if above (progn - (goto-char start) + (select-window (car isearch-windows)) + (goto-char start) (recenter 0) - (when (>= isearch-point (window-end nil t)) - (goto-char isearch-point) + (when (>= isearch-point (isearch-windows-end nil t)) + (select-window (car (last isearch-windows))) + (goto-char isearch-point) (recenter -1))) + (select-window (car (last isearch-windows))) (goto-char end) (recenter -1) - (when (< isearch-point (window-start)) + (when (< isearch-point (isearch-windows-start)) + (select-window (car isearch-windows)) (goto-char isearch-point) (recenter 0)))) (goto-char isearch-point)) @@ -2390,6 +2428,7 @@ (isearch-ring-adjust1 advance) (if search-ring-update (progn + (isearch-call-message nil t) (isearch-search) (isearch-push-state) (isearch-update)) @@ -2462,6 +2501,13 @@ (defun isearch-message (&optional c-q-hack ellipsis) ;; Generate and print the message string. + + ;; N.B.: This function should always be called with point at the + ;; search point, because in certain (rare) circumstances, undesired + ;; scrolling can happen when point is elsewhere. These + ;; circumstances are when follow-mode is active, the search string + ;; spans two (or several) windows, and the message about to be + ;; displayed will cause the echo area to expand. (let ((cursor-in-echo-area ellipsis) (m isearch-message) (fail-pos (isearch-fail-pos t))) @@ -2630,9 +2676,6 @@ (defun isearch-search () ;; Do the search with the current search string. - (if isearch-message-function - (funcall isearch-message-function nil t) - (isearch-message nil t)) (if (and (eq isearch-case-fold-search t) search-upper-case) (setq isearch-case-fold-search (isearch-no-upper-case-p isearch-string isearch-regexp))) @@ -2936,8 +2979,9 @@ (defvar isearch-lazy-highlight-timer nil) (defvar isearch-lazy-highlight-last-string nil) (defvar isearch-lazy-highlight-window nil) -(defvar isearch-lazy-highlight-window-start nil) -(defvar isearch-lazy-highlight-window-end nil) +(defvar isearch-lazy-highlight-windows nil) +(defvar isearch-lazy-highlight-windows-start 0) +(defvar isearch-lazy-highlight-windows-end 0) (defvar isearch-lazy-highlight-case-fold-search nil) (defvar isearch-lazy-highlight-regexp nil) (defvar isearch-lazy-highlight-lax-whitespace nil) @@ -2972,11 +3016,15 @@ search string to change or the window to scroll). It is also used by other Emacs features." (when (and (null executing-kbd-macro) - (sit-for 0) ;make sure (window-start) is credible + ;; make sure (window-start) is credible + (if (and (boundp 'follow-mode) follow-mode) + (progn (follow-adjust-window (selected-window)) + t) + (sit-for 0)) (or (not (equal isearch-string isearch-lazy-highlight-last-string)) - (not (eq (selected-window) - isearch-lazy-highlight-window)) + (not (memq (selected-window) + isearch-lazy-highlight-windows)) (not (eq isearch-lazy-highlight-case-fold-search isearch-case-fold-search)) (not (eq isearch-lazy-highlight-regexp @@ -2987,10 +3035,10 @@ isearch-lax-whitespace)) (not (eq isearch-lazy-highlight-regexp-lax-whitespace isearch-regexp-lax-whitespace)) - (not (= (window-start) - isearch-lazy-highlight-window-start)) - (not (= (window-end) ; Window may have been split/joined. - isearch-lazy-highlight-window-end)) + (not (= (isearch-windows-start isearch-lazy-highlight-windows) + isearch-lazy-highlight-windows-start)) + (not (= (isearch-windows-end isearch-lazy-highlight-windows) ; Window may have been split/joined. + isearch-lazy-highlight-windows-end)) (not (eq isearch-forward isearch-lazy-highlight-forward)) ;; In case we are recovering from an error. @@ -3005,8 +3053,14 @@ (setq isearch-lazy-highlight-start-limit beg isearch-lazy-highlight-end-limit end) (setq isearch-lazy-highlight-window (selected-window) - isearch-lazy-highlight-window-start (window-start) - isearch-lazy-highlight-window-end (window-end) + isearch-lazy-highlight-windows + (if (and (boundp 'follow-mode) follow-mode) + (follow-all-followers) + (list (selected-window))) + isearch-lazy-highlight-windows-start + (isearch-windows-start isearch-lazy-highlight-windows) + isearch-lazy-highlight-windows-end + (isearch-windows-end isearch-lazy-highlight-windows) ;; Start lazy-highlighting at the beginning of the found ;; match (`isearch-other-end'). If no match, use point. ;; One of the next two variables (depending on search direction) @@ -3048,11 +3102,11 @@ (min (or isearch-lazy-highlight-end-limit (point-max)) (if isearch-lazy-highlight-wrapped isearch-lazy-highlight-start - (window-end))) + isearch-lazy-highlight-windows-end)) (max (or isearch-lazy-highlight-start-limit (point-min)) (if isearch-lazy-highlight-wrapped isearch-lazy-highlight-end - (window-start)))))) + isearch-lazy-highlight-windows-start))))) ;; Use a loop like in `isearch-search'. (while retry (setq success (isearch-search-string @@ -3068,6 +3122,24 @@ success) (error nil))) +(defun isearch-lazy-highlight-put-overlays (mb me) + "Put a highlighting overlay on the buffer for each pertinent window. + +An overlay is put over the positions (MB ME) in each window in +`isearch-lazy-highlight-windows' which (at least partially) contains them." + ;; non-zero-length match + (mapc (lambda (w) + (if (and (< mb (window-end w)) + (> me (window-start w))) + (let ((ov (make-overlay mb me))) + (push ov isearch-lazy-highlight-overlays) + ;; 1000 is higher than ediff's 100+, + ;; but lower than isearch main overlay's 1001 + (overlay-put ov 'priority 1000) + (overlay-put ov 'face lazy-highlight-face) + (overlay-put ov 'window w)))) + isearch-lazy-highlight-windows)) + (defun isearch-lazy-highlight-update () "Update highlighting of other matches for current search." (let ((max lazy-highlight-max-at-a-time) @@ -3096,23 +3168,15 @@ (if isearch-lazy-highlight-forward (if (= mb (if isearch-lazy-highlight-wrapped isearch-lazy-highlight-start - (window-end))) + isearch-lazy-highlight-windows-end)) (setq found nil) (forward-char 1)) (if (= mb (if isearch-lazy-highlight-wrapped isearch-lazy-highlight-end - (window-start))) + isearch-lazy-highlight-windows-start)) (setq found nil) (forward-char -1))) - - ;; non-zero-length match - (let ((ov (make-overlay mb me))) - (push ov isearch-lazy-highlight-overlays) - ;; 1000 is higher than ediff's 100+, - ;; but lower than isearch main overlay's 1001 - (overlay-put ov 'priority 1000) - (overlay-put ov 'face lazy-highlight-face) - (overlay-put ov 'window (selected-window)))) + (isearch-lazy-highlight-put-overlays mb me)) ;; Remember the current position of point for ;; the next call of `isearch-lazy-highlight-update' ;; when `lazy-highlight-max-at-a-time' is too small. @@ -3128,12 +3192,12 @@ (setq isearch-lazy-highlight-wrapped t) (if isearch-lazy-highlight-forward (progn - (setq isearch-lazy-highlight-end (window-start)) + (setq isearch-lazy-highlight-end isearch-lazy-highlight-windows-start) (goto-char (max (or isearch-lazy-highlight-start-limit (point-min)) - (window-start)))) - (setq isearch-lazy-highlight-start (window-end)) + isearch-lazy-highlight-windows-start))) + (setq isearch-lazy-highlight-start isearch-lazy-highlight-windows-end) (goto-char (min (or isearch-lazy-highlight-end-limit (point-max)) - (window-end)))))))) + isearch-lazy-highlight-windows-end))))))) (unless nomore (setq isearch-lazy-highlight-timer (run-at-time lazy-highlight-interval nil @@ -3151,6 +3215,7 @@ (setq isearch-string string isearch-message message isearch-case-fold-search case-fold) + (isearch-call-message nil t) (isearch-search) (isearch-update)) -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri May 09 22:40:20 2014 Received: (at 17453) by debbugs.gnu.org; 10 May 2014 02:40:20 +0000 Received: from localhost ([127.0.0.1]:57443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WixD0-0005iW-Nh for submit@debbugs.gnu.org; Fri, 09 May 2014 22:40:19 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:31065) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WixCv-0005iE-E7 for 17453@debbugs.gnu.org; Fri, 09 May 2014 22:40:13 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAIDvNVNMCqwB/2dsb2JhbABZgwaDSr0vgw6BFxd0giYBAQRWIxALDiYSFBgNJIgM0hkXjnoHhDgEqRmBaoNMIQ X-IPAS-Result: ArYGAIDvNVNMCqwB/2dsb2JhbABZgwaDSr0vgw6BFxd0giYBAQRWIxALDiYSFBgNJIgM0hkXjnoHhDgEqRmBaoNMIQ X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="62185951" Received: from 76-10-172-1.dsl.teksavvy.com (HELO pastel.home) ([76.10.172.1]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 09 May 2014 22:40:07 -0400 Received: by pastel.home (Postfix, from userid 20848) id 9762360792; Fri, 9 May 2014 22:40:07 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: References: <20140509224458.GA4205@acm.acm> Date: Fri, 09 May 2014 22:40:07 -0400 In-Reply-To: <20140509224458.GA4205@acm.acm> (Alan Mackenzie's message of "Fri, 9 May 2014 22:44:58 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > +(defvar isearch-windows nil > + "List of windows active in the incremental search. > +This is either the ordered list of active windows administered by > +`follow-mode' or a list of the single window involved in the > +search.") > + > +(defmacro isearch-windows-start (&optional wins) > + "Get the start point of the windows involved in the isearch." > + `(window-start (car ,(if wins wins 'isearch-windows)))) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (or wins 'isearch-windows) I must say I really dislike this hard-coding of follow-mode support in isearch.el. Isearch should not know so much about follow-mode and follow-mode should not know so much about Isearch either. IOW we should try harder to come up with more general hooks. > + `(if isearch-message-function > + (funcall isearch-message-function ,cqh ,ellip) > + (isearch-message ,cqh ,ellip))) Aka (funcall (or isearch-message-function #'isearch-message) ,cqh ,ellip) BTW, isearch-message-function should be changed to default to isearch-message rather than to nil. > @@ -2207,10 +2239,12 @@ > together with as much of the search string as will fit; the symbol > `above' if we need to scroll the text downwards; the symbol `below', > if upwards." > - (let ((w-start (window-start)) > - (w-end (window-end nil t)) > - (w-L1 (save-excursion (move-to-window-line 1) (point))) > - (w-L-1 (save-excursion (move-to-window-line -1) (point))) > + (let ((w-start (isearch-windows-start)) > + (w-end (isearch-windows-end nil t)) > + (w-L1 (with-selected-window (car isearch-windows) > + (save-excursion (move-to-window-line 1) (point)))) > + (w-L-1 (with-selected-window (car (last isearch-windows)) > + (save-excursion (move-to-window-line -1) (point)))) This isearch-string-out-of-window+isearch-back-into-window business, for example should be generalized to a function along the lines of "bring-region-into-sight". It's not useful only for isearch. E.g. ediff-next-hunk would also benefit from it. And of course, it should come with a bring-region-into-sight-function hook (which does not default to nil but to the default implementation), which follow-mode can then override. > + ;; 1000 is higher than ediff's 100+, [ Side note: Ediff doesn't use priorities any more. ] Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 09:02:57 2014 Received: (at 17453) by debbugs.gnu.org; 11 May 2014 13:02:57 +0000 Received: from localhost ([127.0.0.1]:58841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjTP6-0001Q8-DZ for submit@debbugs.gnu.org; Sun, 11 May 2014 09:02:56 -0400 Received: from colin.muc.de ([193.149.48.1]:19641 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjTP1-0001Pu-PY for 17453@debbugs.gnu.org; Sun, 11 May 2014 09:02:52 -0400 Received: (qmail 80130 invoked by uid 3782); 11 May 2014 13:02:49 -0000 Received: from acm.muc.de (pD9518079.dip0.t-ipconnect.de [217.81.128.121]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 11 May 2014 15:02:47 +0200 Received: (qmail 12904 invoked by uid 1000); 11 May 2014 12:58:42 -0000 Date: Sun, 11 May 2014 12:58:42 +0000 To: Stefan Monnier Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20140511125842.GA11781@acm.acm> References: <20140509224458.GA4205@acm.acm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) Hello, Stefan. On Fri, May 09, 2014 at 10:40:07PM -0400, Stefan Monnier wrote: > I must say I really dislike this hard-coding of follow-mode support in > isearch.el. Isearch should not know so much about follow-mode and > follow-mode should not know so much about Isearch either. Follow Mode knows nothing of Isearch. The problem the other way round is in Lisp files that themselves play with redisplay (including calling `sit-for') and `set-window-start', and so on. Between these invocations and the actual redisplay, Follow Mode must get a chance to make its adjustments. > IOW we should try harder to come up with more general hooks. For what? Given that Follow Mode uses a list of windows where most elisp programs (including Isearch up till now) are expecting to deal with a single window, there is quite a large clash, possibly unbridgeable with any reasonable amount of effort. Some sort of abstraction that smoothes over the difference between the window and the window list is difficult to conceive of - Follow Mode itself is such an abstraction. Maybe a useful hook here would be `redisplay-hook' where Follow Mode could do its stuff more effectively than on `post-command-hook'. The extreme solution would be to enhance the display code to handle multiple column windows, rendering Follow Mode redundant. I don't think anybody with the expertise has the time for this. > > @@ -2207,10 +2239,12 @@ > > together with as much of the search string as will fit; the symbol > > `above' if we need to scroll the text downwards; the symbol `below', > > if upwards." > > - (let ((w-start (window-start)) > > - (w-end (window-end nil t)) > > - (w-L1 (save-excursion (move-to-window-line 1) (point))) > > - (w-L-1 (save-excursion (move-to-window-line -1) (point))) > > + (let ((w-start (isearch-windows-start)) > > + (w-end (isearch-windows-end nil t)) > > + (w-L1 (with-selected-window (car isearch-windows) > > + (save-excursion (move-to-window-line 1) (point)))) > > + (w-L-1 (with-selected-window (car (last isearch-windows)) > > + (save-excursion (move-to-window-line -1) (point)))) > This isearch-string-out-of-window+isearch-back-into-window business, for > example should be generalized to a function along the lines of > "bring-region-into-sight". It's not useful only for isearch. This seems to be a different bug to the one I reported, and orthogonal to it. > E.g. ediff-next-hunk would also benefit from it. Not necessarily. isearch-back-into-window, in addition to doing "bring-region-into-sight" ensures that it's the isearch-point end of it which is visible when it is too big for the window. This may be problematic for other uses, like in ediff. > And of course, it should come with a bring-region-into-sight-function > hook (which does not default to nil but to the default implementation), > which follow-mode can then override. Yes. Question is, what about the main bug? The patch I wrote fixes a real bug, and works (modulo any remaining bugs). Do you have any concrete suggestions as to how to improve the fix? > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 12:09:48 2014 Received: (at 17453) by debbugs.gnu.org; 11 May 2014 16:09:48 +0000 Received: from localhost ([127.0.0.1]:59447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjWJv-0006an-6u for submit@debbugs.gnu.org; Sun, 11 May 2014 12:09:47 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:30184) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjWJt-0006aV-1K for 17453@debbugs.gnu.org; Sun, 11 May 2014 12:09:45 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAIDvNVNMCqwB/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCw4mEhQYDSSIBAjSGReOegeEOASpGYFqg0wh X-IPAS-Result: ArYGAIDvNVNMCqwB/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCw4mEhQYDSSIBAjSGReOegeEOASpGYFqg0wh X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="62342447" Received: from 76-10-172-1.dsl.teksavvy.com (HELO pastel.home) ([76.10.172.1]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 May 2014 12:09:39 -0400 Received: by pastel.home (Postfix, from userid 20848) id 0EA17602A0; Sun, 11 May 2014 12:09:39 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: References: <20140509224458.GA4205@acm.acm> <20140511125842.GA11781@acm.acm> Date: Sun, 11 May 2014 12:09:38 -0400 In-Reply-To: <20140511125842.GA11781@acm.acm> (Alan Mackenzie's message of "Sun, 11 May 2014 12:58:42 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Follow Mode knows nothing of Isearch. follow-mode.el doesn't, indeed, but since you're moving some follow mode code to isearch.el, that means that follow mode (which is now spread over follow-mode.el and isearch.el) knows something about Isearch. > The problem the other way round is in Lisp files that themselves play > with redisplay (including calling `sit-for') and `set-window-start', > and so on. Between these invocations and the actual redisplay, Follow > Mode must get a chance to make its adjustments. There's no doubt that follow mode's task is a tricky one, and I'm willing to add special support for it. I just want this special support to be a bit more generic than what you provided. It shouldn't be too difficult. It's just a matter of refactoring: change your patch so that on isearch.el's side it only adds some hooks, which are then set follow-mode.el. >> IOW we should try harder to come up with more general hooks. > For what? So that the same hooks can be used by other code than Isearch, for example. > Maybe a useful hook here would be `redisplay-hook' where Follow Mode > could do its stuff more effectively than on `post-command-hook'. There's pre-redisplay-function, which I think it does get us closer but is not sufficient yet. And of course, it won't help with things like "bring-region-into-sight". >> > @@ -2207,10 +2239,12 @@ >> > together with as much of the search string as will fit; the symbol >> > `above' if we need to scroll the text downwards; the symbol `below', >> > if upwards." >> > - (let ((w-start (window-start)) >> > - (w-end (window-end nil t)) >> > - (w-L1 (save-excursion (move-to-window-line 1) (point))) >> > - (w-L-1 (save-excursion (move-to-window-line -1) (point))) >> > + (let ((w-start (isearch-windows-start)) >> > + (w-end (isearch-windows-end nil t)) >> > + (w-L1 (with-selected-window (car isearch-windows) >> > + (save-excursion (move-to-window-line 1) (point)))) >> > + (w-L-1 (with-selected-window (car (last isearch-windows)) >> > + (save-excursion (move-to-window-line -1) (point)))) >> This isearch-string-out-of-window+isearch-back-into-window business, for >> example should be generalized to a function along the lines of >> "bring-region-into-sight". It's not useful only for isearch. > This seems to be a different bug to the one I reported, and orthogonal > to it. What bug? I'm just pointing out that the code you're modifying is more generally useful and that this generality is a good guide to help us decide where to put needed hooks. >> E.g. ediff-next-hunk would also benefit from it. ^^^^^ I meant "diff", sorry. Tho it would also be useful to ediff and smerge-mode as well, indeed. > Not necessarily. isearch-back-into-window, in addition to doing > "bring-region-into-sight" ensures that it's the isearch-point end of it > which is visible when it is too big for the window. This may be > problematic for other uses, like in ediff. I doubt this will be problematic. It seems quite natural for "bring-region-into-sight" to take as arguments not just the region but also some indication of the part to favor in case it can't all be displayed. > Question is, what about the main bug? The patch I wrote fixes a real > bug, and works (modulo any remaining bugs). Do you have any concrete > suggestions as to how to improve the fix? Hmm... I'm sorry I got lost along the way. I thought the whole patch is the bug fix (and the bring-region-into-sight part does seem like a bug-fix as well, tho maybe of top priority, admittedly). Could you show which part of the patch addresses the main bug? Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 14:22:43 2014 Received: (at 17453) by debbugs.gnu.org; 11 May 2014 18:22:43 +0000 Received: from localhost ([127.0.0.1]:59558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjYOY-0002yp-NQ for submit@debbugs.gnu.org; Sun, 11 May 2014 14:22:43 -0400 Received: from colin.muc.de ([193.149.48.1]:61411 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjYOV-0002yf-H8 for 17453@debbugs.gnu.org; Sun, 11 May 2014 14:22:40 -0400 Received: (qmail 98238 invoked by uid 3782); 11 May 2014 18:22:38 -0000 Received: from acm.muc.de (pD951AB04.dip0.t-ipconnect.de [217.81.171.4]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 11 May 2014 20:22:37 +0200 Received: (qmail 3373 invoked by uid 1000); 11 May 2014 18:18:32 -0000 Date: Sun, 11 May 2014 18:18:32 +0000 To: Stefan Monnier Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20140511181832.GA2759@acm.acm> References: <20140509224458.GA4205@acm.acm> <20140511125842.GA11781@acm.acm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) Hello, Stefan. On Sun, May 11, 2014 at 12:09:38PM -0400, Stefan Monnier wrote: > > Follow Mode knows nothing of Isearch. > follow-mode.el doesn't, indeed, but since you're moving some follow mode > code to isearch.el, .... Am I? No code that currently is in follow-mode.el will cease to be in follow-mode.el. > .... that means that follow mode (which is now spread > over follow-mode.el and isearch.el) knows something about Isearch. No, Follow Mode will know nothing about Isearch. Isearch will know about follow-mode's internal structures, namely its list of windows, and what their sequencing means. In that sense, the two libraries are coupled, which isn't, other things being equal, good, but I can't see how to avoid it. Can you see a way of avoiding this coupling? > > The problem the other way round is in Lisp files that themselves play > > with redisplay (including calling `sit-for') and `set-window-start', > > and so on. Between these invocations and the actual redisplay, Follow > > Mode must get a chance to make its adjustments. > There's no doubt that follow mode's task is a tricky one, and I'm > willing to add special support for it. I just want this special support > to be a bit more generic than what you provided. I'm having trouble discerning WHAT, specifically, should be made more generic (with the exception of the two functions discussed below). Could you talk more in specifics, please. > It shouldn't be too difficult. It's just a matter of refactoring: > change your patch so that on isearch.el's side it only adds some hooks, > which are then set follow-mode.el. Do you mean "set to a function in follow-mode.el". I think you're suggesting writing more functions in follow-mode.el. Do you mean something like a Follow Mode equivalent of `window-start'? > >> IOW we should try harder to come up with more general hooks. > > For what? > So that the same hooks can be used by other code than Isearch, for example. I know the motivation for the change. For what functionalities should code be come up with that will be incorporated into these hooks? What will the hooks do, specifically? > > Maybe a useful hook here would be `redisplay-hook' where Follow Mode > > could do its stuff more effectively than on `post-command-hook'. > There's pre-redisplay-function, which I think it does get us closer but > is not sufficient yet. And of course, it won't help with things > like "bring-region-into-sight". I didn't know about pre-redisplay-function. It looks new. As an aside, its documentation is unclear (what is a "set" of windows, for example, and what sort of things are allowed/not allowed in a hook function (deleting windows, for example)?) Is it for "bring-region-into-sight" and friends that you envisage adding hooks? > >> > @@ -2207,10 +2239,12 @@ > >> > together with as much of the search string as will fit; the symbol > >> > `above' if we need to scroll the text downwards; the symbol `below', > >> > if upwards." > >> > - (let ((w-start (window-start)) > >> > - (w-end (window-end nil t)) > >> > - (w-L1 (save-excursion (move-to-window-line 1) (point))) > >> > - (w-L-1 (save-excursion (move-to-window-line -1) (point))) > >> > + (let ((w-start (isearch-windows-start)) > >> > + (w-end (isearch-windows-end nil t)) > >> > + (w-L1 (with-selected-window (car isearch-windows) > >> > + (save-excursion (move-to-window-line 1) (point)))) > >> > + (w-L-1 (with-selected-window (car (last isearch-windows)) > >> > + (save-excursion (move-to-window-line -1) (point)))) > >> This isearch-string-out-of-window+isearch-back-into-window business, for > >> example should be generalized to a function along the lines of > >> "bring-region-into-sight". It's not useful only for isearch. > > This seems to be a different bug to the one I reported, and orthogonal > > to it. > What bug? I'm just pointing out that the code you're modifying is more > generally useful and that this generality is a good guide to help us > decide where to put needed hooks. I meant that forming a more general subroutine out of isearch-back-into-window is not properly part of bug #17453. It is a separate exercise, which can be done independently of #17453. I'm not sure how well a hook would work for this functionality, since in the "plain" hook function you'd want to pass it a window, whereas in the "follow" hook function you'd want to pass it a list of windows. > >> E.g. ediff-next-hunk would also benefit from it. > ^^^^^ > I meant "diff", sorry. Tho it would also be useful to ediff and smerge-mode > as well, indeed. OK. So you're thinking of somewhere like subr.el, with something like (defun scroll-region-into-window/s (start end window/s above opposite-important) ....) where WINDOW/S is either a single window or a list of them, START END bound the region, OPPOSITE-IMPORTANT is t when the region boundary "nearest the window" is to be preferred for display when the region's too big. Or something like that. Maybe we could add a parameter for desired margin at the top/bottom of the window. > > Not necessarily. isearch-back-into-window, in addition to doing > > "bring-region-into-sight" ensures that it's the isearch-point end of it > > which is visible when it is too big for the window. This may be > > problematic for other uses, like in ediff. > I doubt this will be problematic. It seems quite natural for > "bring-region-into-sight" to take as arguments not just the region but > also some indication of the part to favor in case it can't all > be displayed. OK. Formulating a good description of that parameter is tricky, though. > > Question is, what about the main bug? The patch I wrote fixes a real > > bug, and works (modulo any remaining bugs). Do you have any concrete > > suggestions as to how to improve the fix? > Hmm... I'm sorry I got lost along the way. I thought the whole patch is > the bug fix (and the bring-region-into-sight part does seem like > a bug-fix as well, tho maybe of top priority, admittedly). > Could you show which part of the patch addresses the main bug? The whole patch addresses the main bug; forming generally useful subroutines out of isearch-string-out-of-window and friends is the other bug, which I'm suggesting be dealt with separately. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 15:05:26 2014 Received: (at 17453) by debbugs.gnu.org; 11 May 2014 19:05:27 +0000 Received: from localhost ([127.0.0.1]:59591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjZ3u-0004DH-AL for submit@debbugs.gnu.org; Sun, 11 May 2014 15:05:26 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:45099) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjZ3r-0004D4-Me for 17453@debbugs.gnu.org; Sun, 11 May 2014 15:05:24 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNMCqwB/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kLodWCNIZF456B4Q4BKkZgWqDTCE X-IPAS-Result: ArUGAIDvNVNMCqwB/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kLodWCNIZF456B4Q4BKkZgWqDTCE X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="62358016" Received: from 76-10-172-1.dsl.teksavvy.com (HELO pastel.home) ([76.10.172.1]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 May 2014 15:05:17 -0400 Received: by pastel.home (Postfix, from userid 20848) id 60C0D602A0; Sun, 11 May 2014 15:05:17 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: References: <20140509224458.GA4205@acm.acm> <20140511125842.GA11781@acm.acm> <20140511181832.GA2759@acm.acm> Date: Sun, 11 May 2014 15:05:17 -0400 In-Reply-To: <20140511181832.GA2759@acm.acm> (Alan Mackenzie's message of "Sun, 11 May 2014 18:18:32 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> follow-mode.el doesn't, indeed, but since you're moving some follow mode >> code to isearch.el, .... > Am I? No code that currently is in follow-mode.el will cease to be in > follow-mode.el. Please replace "moving" with "adding" in my phrase, then. > No, Follow Mode will know nothing about Isearch. Isearch will know about > follow-mode's internal structures, namely its list of windows, and what > their sequencing means. In that sense, the two libraries are coupled, > which isn't, other things being equal, good, but I can't see how to > avoid it. Can you see a way of avoiding this coupling? I gave one suggestion to uncouple them in one specific spot, yes. There's no general answer for such problems, so we have to look at every part of the coupling and try to find solutions for each part. >> It shouldn't be too difficult. It's just a matter of refactoring: >> change your patch so that on isearch.el's side it only adds some hooks, >> which are then set follow-mode.el. > Do you mean "set to a function in follow-mode.el". I think you're > suggesting writing more functions in follow-mode.el. Do you mean > something like a Follow Mode equivalent of `window-start'? Right, I think introducing new functions/hooks to get the beginning/end of the visible part of the buffer, which can then be overridden by follow-mode would probably be part of the solution. > I know the motivation for the change. For what functionalities should > code be come up with that will be incorporated into these hooks? What > will the hooks do, specifically? I don't know. You know the code better than I do, so hopefully you can come up with good ideas. > I didn't know about pre-redisplay-function. It looks new. As an aside, > its documentation is unclear (what is a "set" of windows, for example, As is common in (Emacs) Lisp, sets are represented as a list. > and what sort of things are allowed/not allowed in a hook function > (deleting windows, for example)?) Noone knows, really. > Is it for "bring-region-into-sight" and friends that you envisage adding > hooks? Yes. > I'm not sure how well a hook would work for this functionality, since in > the "plain" hook function you'd want to pass it a window, whereas in the > "follow" hook function you'd want to pass it a list of windows. I don't see why you'd need to pass anything like a window or a list of windows. All it needs is a region and a point. The window (or set thereof) would be passed implicitly via selected-window, as usual. > OK. So you're thinking of somewhere like subr.el, with something like > (defun scroll-region-into-window/s (start end window/s above > opposite-important) ....) > where WINDOW/S is either a single window or a list of them, START END > bound the region, OPPOSITE-IMPORTANT is t when the region boundary > "nearest the window" is to be preferred for display when the region's too > big. Or something like that. Maybe we could add a parameter for desired > margin at the top/bottom of the window. Something like that, yes. > OK. Formulating a good description of that parameter is tricky, though. Right, designing an API is often tricky. > The whole patch addresses the main bug; forming generally useful > subroutines out of isearch-string-out-of-window and friends is the other > bug, which I'm suggesting be dealt with separately. I don't want to add code specific to follow-mode directly in Isearch. So the way to fix the bug is in 2 steps: - refactor Isearch so that it adds the hooks we need (some of this, may involve creating new functions in subr.el such as discussed above). - change follow-mode.el to set those hooks as appropriate. There's then a 3rd step which is to make other packages than Isearch use those same new functions/hooks, but that one can be postponed. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 16:44:28 2014 Received: (at 17453) by debbugs.gnu.org; 11 May 2014 20:44:28 +0000 Received: from localhost ([127.0.0.1]:59715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wjabj-00071F-E9 for submit@debbugs.gnu.org; Sun, 11 May 2014 16:44:27 -0400 Received: from colin.muc.de ([193.149.48.1]:54757 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wjabg-000710-Sw for 17453@debbugs.gnu.org; Sun, 11 May 2014 16:44:25 -0400 Received: (qmail 4972 invoked by uid 3782); 11 May 2014 20:44:23 -0000 Received: from acm.muc.de (pD951AB04.dip0.t-ipconnect.de [217.81.171.4]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 11 May 2014 22:44:22 +0200 Received: (qmail 3696 invoked by uid 1000); 11 May 2014 20:40:17 -0000 Date: Sun, 11 May 2014 20:40:17 +0000 To: Stefan Monnier Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20140511204017.GB2759@acm.acm> References: <20140509224458.GA4205@acm.acm> <20140511125842.GA11781@acm.acm> <20140511181832.GA2759@acm.acm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) Hello, Stefan. On Sun, May 11, 2014 at 03:05:17PM -0400, Stefan Monnier wrote: > >> It shouldn't be too difficult. It's just a matter of refactoring: > >> change your patch so that on isearch.el's side it only adds some hooks, > >> which are then set follow-mode.el. > > Do you mean "set to a function in follow-mode.el". I think you're > > suggesting writing more functions in follow-mode.el. Do you mean > > something like a Follow Mode equivalent of `window-start'? > Right, I think introducing new functions/hooks to get the beginning/end of the > visible part of the buffer, which can then be overridden by follow-mode > would probably be part of the solution. OK, but it really needs a window list as a parameter, and that needs to be stored in a variable somewhere. > > I know the motivation for the change. For what functionalities should > > code be come up with that will be incorporated into these hooks? What > > will the hooks do, specifically? > I don't know. You know the code better than I do, so hopefully you can > come up with good ideas. I don't really see opportunities for this whose costs don't outweigh them. We can make a variable called `window-start-function', but then everybody has to start using (funcall window-start-function w) which is a little more obfuscated and confusing than (window-start w) just to save a (very) few calls of (window-start (car foo-windows)) . The last form is typically going to be much faster when Follow Mode is active (see below). [ Snipped bit about pre-redisplay-function. Thanks. ] > > Is it for "bring-region-into-sight" and friends that you envisage adding > > hooks? > Yes. > > I'm not sure how well a hook would work for this functionality, since in > > the "plain" hook function you'd want to pass it a window, whereas in the > > "follow" hook function you'd want to pass it a list of windows. > I don't see why you'd need to pass anything like a window or a list > of windows. All it needs is a region and a point. The window (or set > thereof) would be passed implicitly via selected-window, as usual. Because each time the Follow Mode window list would have to be recalculated, and this is a moderately expensive calculation, involving filtering and sorting the windows in a frame (`follow-all-followers'). This is no big deal once per command, but if done much more often will start to drag. [ .... ] > Right, designing an API is often tricky. :-) > > The whole patch addresses the main bug; forming generally useful > > subroutines out of isearch-string-out-of-window and friends is the other > > bug, which I'm suggesting be dealt with separately. > I don't want to add code specific to follow-mode directly in Isearch. There is one place where I think it is unavoidable, and that is adding lazy highlight overlays. These are currently given a `window' property to restrict their effect to the current window. In my patch, a particular match gets _two_ (or even several) overlays when it spans two or more Follow Mode windows. This can surely not be abstracted away in any sensible way. > So the way to fix the bug is in 2 steps: > - refactor Isearch so that it adds the hooks we need (some of this, > may involve creating new functions in subr.el such as discussed above). > - change follow-mode.el to set those hooks as appropriate. > There's then a 3rd step which is to make other packages than Isearch use > those same new functions/hooks, but that one can be postponed. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 17:47:03 2014 Received: (at 17453) by debbugs.gnu.org; 11 May 2014 21:47:04 +0000 Received: from localhost ([127.0.0.1]:59785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjbaJ-0001PS-1U for submit@debbugs.gnu.org; Sun, 11 May 2014 17:47:03 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:25007) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjbaG-0001Oj-CZ for 17453@debbugs.gnu.org; Sun, 11 May 2014 17:47:01 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVMXW5vY/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kLodWCNIZF456B4Q4BKsDg0wh X-IPAS-Result: ArUGAIDvNVMXW5vY/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kLodWCNIZF456B4Q4BKsDg0wh X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="62368934" Received: from 23-91-155-216.cpe.pppoe.ca (HELO pastel.home) ([23.91.155.216]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 May 2014 17:46:53 -0400 Received: by pastel.home (Postfix, from userid 20848) id 891CD600A4; Sun, 11 May 2014 17:46:53 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: References: <20140509224458.GA4205@acm.acm> <20140511125842.GA11781@acm.acm> <20140511181832.GA2759@acm.acm> <20140511204017.GB2759@acm.acm> Date: Sun, 11 May 2014 17:46:53 -0400 In-Reply-To: <20140511204017.GB2759@acm.acm> (Alan Mackenzie's message of "Sun, 11 May 2014 20:40:17 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> Right, I think introducing new functions/hooks to get the >> beginning/end of the visible part of the buffer, which can then be >> overridden by follow-mode would probably be part of the solution. > OK, but it really needs a window list as a parameter, and that needs to > be stored in a variable somewhere. I don't understand. Why would it need to be both in a parameter and in a variable somewhere? And isn't it already in some follow-mode "variable" somewhere? window-start does not need a window parameter (it does accept such a parameter, optionally, but that's just to avoid some with-selected-window), so I don't think such new function would need such a parameter either. > I don't really see opportunities for this whose costs don't outweigh > them. We can make a variable called `window-start-function', but then > everybody has to start using > (funcall window-start-function w) I see two options: - either some/many calls need to be changed to use the new API. - or follow-mode advises window-start. And of course, it would be (funcall window-start-function), without the `w'. > which is a little more obfuscated and confusing than > (window-start w) To make it less obfuscated, we can provide a new function `viewable-area-start' which does (funcall window-start-function). > . The last form is typically going to be much faster when Follow Mode is > active (see below). Not sure about "much". My gut feeling would be rather around "not noticeably". >> I don't see why you'd need to pass anything like a window or a list >> of windows. All it needs is a region and a point. The window (or set >> thereof) would be passed implicitly via selected-window, as usual. > Because each time the Follow Mode window list I don't see why. Isn't/can't the "Follow Mode window list" be kept as a window-parameter, so you can get it quickly? > would have to be recalculated, and this is a moderately expensive > calculation, involving filtering and sorting the windows in a frame > (`follow-all-followers'). This is no big deal once per command, but > if done much more often will start to drag. Indeed, recomputing it for every window-start call would make it expensive. I assume that it can be cached such that we only recompute it when it changes (e.g. using window-configuration-change-hook). > There is one place where I think it is unavoidable, and that is adding > lazy highlight overlays. These are currently given a `window' property > to restrict their effect to the current window. In my patch, a > particular match gets _two_ (or even several) overlays when it spans two > or more Follow Mode windows. This can surely not be abstracted away in > any sensible way. You might be right. As mentioned, I think follow-mode is important enough to warrant special treatment, so we can probably leave a few hacks in there, in case no useful/sensible abstraction can be invented. In this case of isearch-vs-followmode, I think the way to find the useful abstractions is to try and figure out "what would be useful/useable for other packages than isearch". Window-specific overlays are not used very often, the candidates seem to be: - region highlighting. - rectangular region highlighting. - compare-w.el. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 29 19:21:21 2015 Received: (at 17453) by debbugs.gnu.org; 29 Oct 2015 23:21:21 +0000 Received: from localhost ([127.0.0.1]:44900 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZrwVV-0008OR-9i for submit@debbugs.gnu.org; Thu, 29 Oct 2015 19:21:21 -0400 Received: from mail.muc.de ([193.149.48.3]:43475) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZrwVT-0008OI-BD for 17453@debbugs.gnu.org; Thu, 29 Oct 2015 19:21:20 -0400 Received: (qmail 24822 invoked by uid 3782); 29 Oct 2015 23:21:16 -0000 Received: from acm.muc.de (p548A58AB.dip0.t-ipconnect.de [84.138.88.171]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 30 Oct 2015 00:21:16 +0100 Received: (qmail 12481 invoked by uid 1000); 29 Oct 2015 23:23:02 -0000 Date: Thu, 29 Oct 2015 23:23:02 +0000 To: Stefan Monnier Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151029232302.GB3812@acm.fritz.box> References: <20140509224458.GA4205@acm.acm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, emacs-devel@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Stefan, hello, Emacs. Resuming a conversation from a year and a half ago, in it I had proposed a patch which made isearch work properly in a Follow Mode set of windows. In the end, you rejected my patch (in effect), because... On Fri, May 09, 2014 at 10:40:07PM -0400, Stefan Monnier wrote: > I must say I really dislike this hard-coding of follow-mode support in > isearch.el. Isearch should not know so much about follow-mode and > follow-mode should not know so much about Isearch either. > IOW we should try harder to come up with more general hooks. That irritated me at the time, but you were right - putting Follow Mode support directly into isearch would not have been a good idea. I've recently started working on the bug again, and although it's not your job anymore, I'd still appreciate you giving me some feedback on my new approach. What I propose is that several functions which operate on windows have extended versions which operate on @dfn{groups of windows}, this meaning (for the moment) Follow Mode groups of windows. These new functions are flexible enough to work with methods other than Follow Mode of grouping windows, should such ever be implemented. The new functions are window*-start, window*-end, set-window*-start, recenter*, pos-visible-in-window*-p, move-to-window*-line, and sit*-for. window*-start returns the window-start of the _first_ window in the group, window*-end returns the window-end of the _last_ window in the group, and so on, all these functions doing the Right Thing for a group of windows. sit*-for exists, because Follow Mode needs a chance to resynchronise its windows before redisplay happens. If Follow Mode is not enabled, all the above functions do the Right Thing on the single window. In addition, there is a function window*-windows, which returns an ordered list of the windows involved (or a list of the single window when F.M. is not active). I have a trial implementation of the above, and a trial adaptation of isearch.el which uses it. It works. What do you think? > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 31 18:35:48 2015 Received: (at 17453) by debbugs.gnu.org; 31 Oct 2015 22:35:48 +0000 Received: from localhost ([127.0.0.1]:47349 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZsekV-0001Bo-RY for submit@debbugs.gnu.org; Sat, 31 Oct 2015 18:35:48 -0400 Received: from mail-pa0-f54.google.com ([209.85.220.54]:33319) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZsekB-0001BK-Jx for 17453@debbugs.gnu.org; Sat, 31 Oct 2015 18:35:46 -0400 Received: by padhy1 with SMTP id hy1so102189893pad.0 for <17453@debbugs.gnu.org>; Sat, 31 Oct 2015 15:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:in-reply-to:date:organization:message-id :references:user-agent:mail-followup-to:mime-version:content-type; bh=6LRnUMgZiB/qph/3fRo1OPsdwXfdYrU+mjH4DypTvh4=; b=Yvbf5/MZDNNcYiJPjn3LeS0nSxM9HkCy4VZFpXYFFUwYqi3GEjyn4wWMJw0hnh2u59 vHx88zuSpaMFcIEKA31RtWkf5BJUCPtO235sBQkWFQ2dia0KHqdc+bs6WMVQq2mbSUXX pRZno1PoilGADMbdQ7euk+v8bIvT5XQGb1zgWWjY/TSdKh9V6aaHzZx8lg+z7udIyogt NAXSE6eIvZotHGZGVXOigS3Aa9dQUBS8iNYL+TP9JdomdyuRDahV/ylZhh6Npjms4RNk eey3PO/pwn7J0mJZoBJSz/dk9eye/kqd4JdRkb/ZRG8W0thaDVvIR5hDO0Sek0ztFWPH yufw== X-Received: by 10.68.239.131 with SMTP id vs3mr8775556pbc.61.1446330926576; Sat, 31 Oct 2015 15:35:26 -0700 (PDT) Received: from Vulcan.attlocal.net (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id ey17sm15682471pac.26.2015.10.31.15.35.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 31 Oct 2015 15:35:25 -0700 (PDT) Received: by Vulcan.attlocal.net (Postfix, from userid 501) id 1B5251022C328; Sat, 31 Oct 2015 15:35:25 -0700 (PDT) From: "John Wiegley" To: Alan Mackenzie Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. In-Reply-To: <20151029232302.GB3812@acm.fritz.box> (Alan Mackenzie's message of "Thu, 29 Oct 2015 23:23:02 +0000") Date: Sat, 31 Oct 2015 15:35:22 -0700 Organization: New Artisans LLC Message-ID: References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Mail-Followup-To: Alan Mackenzie , Stefan Monnier , 17453@debbugs.gnu.org, emacs-devel@gnu.org MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >>>>> Alan Mackenzie writes: > The new functions are window*-start, window*-end, set-window*-start, > recenter*, pos-visible-in-window*-p, move-to-window*-line, and sit*-for. > > window*-start returns the window-start of the _first_ window in the group, > window*-end returns the window-end of the _last_ window in the group, and so > on, all these functions doing the Right Thing for a group of windows. > sit*-for exists, because Follow Mode needs a chance to resynchronise its > windows before redisplay happens. What is the reason for having separate functions such as window*-start, instead of just taking the car of a list of windows? I may be missing some context here, but this sounds like special-casing general behavior, and I'm wondering why it's necessary... John From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 31 19:13:37 2015 Received: (at 17453) by debbugs.gnu.org; 31 Oct 2015 23:13:37 +0000 Received: from localhost ([127.0.0.1]:47364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZsfL7-00029p-5x for submit@debbugs.gnu.org; Sat, 31 Oct 2015 19:13:37 -0400 Received: from mail-lb0-f170.google.com ([209.85.217.170]:33407) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZsfL5-00029h-3e for 17453@debbugs.gnu.org; Sat, 31 Oct 2015 19:13:35 -0400 Received: by lbbec13 with SMTP id ec13so68857200lbb.0 for <17453@debbugs.gnu.org>; Sat, 31 Oct 2015 16:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EMFsvxoiI7kbaHZ3p/XQ/evRC8YhWTpjNVqg4GMqB1Q=; b=WSWELldmgnt8d8TaiIYVwCjKfpxuC/VX2vmK/toBUeEialDEOFg0yYfbggh4A6Ty4c bRmVvlHjl+uTBQsY8xG91eOMl75FBVdhfDquXSHe3M2MpekgEZdQXOn6v0ita5NHbd3D zru8Cphdaw4SfzYa/sy2XsuwNpvUQEl1EjsDF/JbLnweGNVhXoQt/O2bgZo/O7lvyzGY FMvMZ95I/beGMO+qDFgoiSXV65UwVuqsJkugOAaN8rUnqevxrbHTkefCpItRqBA5tBg0 ijxR8GVIMQSP1PUZK2od7tYhnXluEecLK/5XYSQ5Hk+lrsBQcf/KHBvMzcTkGwPib/MP ytzA== MIME-Version: 1.0 X-Received: by 10.112.135.233 with SMTP id pv9mr7058495lbb.42.1446333214447; Sat, 31 Oct 2015 16:13:34 -0700 (PDT) Received: by 10.112.63.71 with HTTP; Sat, 31 Oct 2015 16:13:34 -0700 (PDT) Received: by 10.112.63.71 with HTTP; Sat, 31 Oct 2015 16:13:34 -0700 (PDT) In-Reply-To: <20151029232302.GB3812@acm.fritz.box> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> Date: Sat, 31 Oct 2015 23:13:34 +0000 X-Google-Sender-Auth: ApHX-jzTU7m1StmTVAd3RWZb5AE Message-ID: Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. From: Artur Malabarba To: Alan Mackenzie Content-Type: multipart/alternative; boundary=089e01228934795d1f05236eb1a9 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bruce.connor.am@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e01228934795d1f05236eb1a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29 Oct 2015 11:23 pm, "Alan Mackenzie" wrote: > > Hello, Stefan, hello, Emacs. > > Resuming a conversation from a year and a half ago, in it I had proposed > a patch which made isearch work properly in a Follow Mode set of > windows. In the end, you rejected my patch (in effect), because... > > On Fri, May 09, 2014 at 10:40:07PM -0400, Stefan Monnier wrote: > > > I must say I really dislike this hard-coding of follow-mode support in > > isearch.el. Isearch should not know so much about follow-mode and > > follow-mode should not know so much about Isearch either. > > > IOW we should try harder to come up with more general hooks. What if isearch just took into account all windows displaying current-buffer, instead of just the selected one? This wouldn=E2=80=99t involve anything specific to follow mode, and I belie= ve it would solve the issue, no? --089e01228934795d1f05236eb1a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 29 Oct 2015 11:23 pm, "Alan Mackenzie" <acm@muc.de> wrote:
>
> Hello, Stefan, hello, Emacs.
>
> Resuming a conversation from a year and a half ago, in it I had propos= ed
> a patch which made isearch work properly in a Follow Mode set of
> windows.=C2=A0 In the end, you rejected my patch (in effect), because.= ..
>
> On Fri, May 09, 2014 at 10:40:07PM -0400, Stefan Monnier wrote:
>
> > I must say I really dislike this hard-coding of follow-mode suppo= rt in
> > isearch.el.=C2=A0 Isearch should not know so much about follow-mo= de and
> > follow-mode should not know so much about Isearch either.
>
> > IOW we should try harder to come up with more general hooks.

What if isearch just took into account all windows displayin= g current-buffer, instead of just the selected one?
This wouldn=E2=80=99t involve anything specific to follow mode, and I belie= ve it would solve the issue, no?

--089e01228934795d1f05236eb1a9-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 31 19:23:56 2015 Received: (at 17453) by debbugs.gnu.org; 31 Oct 2015 23:23:56 +0000 Received: from localhost ([127.0.0.1]:47374 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZsfV5-0002PY-Gm for submit@debbugs.gnu.org; Sat, 31 Oct 2015 19:23:55 -0400 Received: from mail.muc.de ([193.149.48.3]:56241) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZsfV3-0002PN-4d for 17453@debbugs.gnu.org; Sat, 31 Oct 2015 19:23:54 -0400 Received: (qmail 92501 invoked by uid 3782); 31 Oct 2015 23:23:51 -0000 Received: from acm.muc.de (p579E9C22.dip0.t-ipconnect.de [87.158.156.34]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 01 Nov 2015 00:23:50 +0100 Received: (qmail 26396 invoked by uid 1000); 31 Oct 2015 23:25:38 -0000 Date: Sat, 31 Oct 2015 23:25:38 +0000 To: Stefan Monnier , 17453@debbugs.gnu.org, emacs-devel@gnu.org Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151031232538.GC1853@acm.fritz.box> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, John. On Sat, Oct 31, 2015 at 03:35:22PM -0700, John Wiegley wrote: > >>>>> Alan Mackenzie writes: > > The new functions are window*-start, window*-end, set-window*-start, > > recenter*, pos-visible-in-window*-p, move-to-window*-line, and sit*-for. > > window*-start returns the window-start of the _first_ window in the group, > > window*-end returns the window-end of the _last_ window in the group, and so > > on, all these functions doing the Right Thing for a group of windows. > > sit*-for exists, because Follow Mode needs a chance to resynchronise its > > windows before redisplay happens. > What is the reason for having separate functions such as window*-start, > instead of just taking the car of a list of windows? I may be missing some > context here, but this sounds like special-casing general behavior, and I'm > wondering why it's necessary... The prime use case is in isearch. At the moment isearch doesn't work well when Follow Mode is active (try it!). My first attempt at amending isearch for this involved manipulating Follow Mode's list of windows directly inside isearch.el. The result was too close a coupling between isearch and Follow Mode, and was also rather ragged. Stefan rejected this patch, asking for a more abstract solution. What I am proposing now is a solution where any library which needs to manipulate things like window positions will be trivially upgradable to working with Follow Mode, merely by replacing `window-start' by `window*-start', etc. The fact that the "group" of windows is represented by a list is an implementation detail to be encapsulated within follow.el. In the (fairly distant) future, this might perhaps be superseded by code in redisplay. Perhaps. > John -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 31 19:30:43 2015 Received: (at 17453) by debbugs.gnu.org; 31 Oct 2015 23:30:43 +0000 Received: from localhost ([127.0.0.1]:47378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zsfbe-0002aP-OC for submit@debbugs.gnu.org; Sat, 31 Oct 2015 19:30:43 -0400 Received: from mail.muc.de ([193.149.48.3]:46708) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zsfbc-0002aG-5J for 17453@debbugs.gnu.org; Sat, 31 Oct 2015 19:30:40 -0400 Received: (qmail 93842 invoked by uid 3782); 31 Oct 2015 23:30:39 -0000 Received: from acm.muc.de (p579E9C22.dip0.t-ipconnect.de [87.158.156.34]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 01 Nov 2015 00:30:37 +0100 Received: (qmail 26432 invoked by uid 1000); 31 Oct 2015 23:32:25 -0000 Date: Sat, 31 Oct 2015 23:32:25 +0000 To: Artur Malabarba Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151031233225.GD1853@acm.fritz.box> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Artur On Sat, Oct 31, 2015 at 11:13:34PM +0000, Artur Malabarba wrote: > On 29 Oct 2015 11:23 pm, "Alan Mackenzie" wrote: > > Hello, Stefan, hello, Emacs. > > Resuming a conversation from a year and a half ago, in it I had proposed > > a patch which made isearch work properly in a Follow Mode set of > > windows. In the end, you rejected my patch (in effect), because... > > On Fri, May 09, 2014 at 10:40:07PM -0400, Stefan Monnier wrote: > > > I must say I really dislike this hard-coding of follow-mode support in > > > isearch.el. Isearch should not know so much about follow-mode and > > > follow-mode should not know so much about Isearch either. > > > IOW we should try harder to come up with more general hooks. > What if isearch just took into account all windows displaying > current-buffer, instead of just the selected one? > This wouldn’t involve anything specific to follow mode, and I believe it > would solve the issue, no? I don't think so, really. What exactly does "took into account" mean? With Follow Mode active, on a forward search you explicitly want point to move into the next window when the search target is visible there. When FM is not active, you most definitely don't want this to happen. I have working code which make isearch and FM work together nicely. I think it's a sufficiently "nice" implementation to commit. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 31 19:37:19 2015 Received: (at 17453) by debbugs.gnu.org; 31 Oct 2015 23:37:20 +0000 Received: from localhost ([127.0.0.1]:47384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zsfi3-0002kH-KL for submit@debbugs.gnu.org; Sat, 31 Oct 2015 19:37:19 -0400 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:53129 helo=homiemail-a13.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zsfi1-0002k8-5H for 17453@debbugs.gnu.org; Sat, 31 Oct 2015 19:37:17 -0400 Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 7E3CB33406F; Sat, 31 Oct 2015 16:37:15 -0700 (PDT) Received: from localhost.linkov.net (m83-176-23-75.cust.tele2.ee [83.176.23.75]) (Authenticated sender: jurta@jurta.org) by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id 0B61B33406B; Sat, 31 Oct 2015 16:37:13 -0700 (PDT) From: Juri Linkov To: Alan Mackenzie Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Organization: LINKOV.NET References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> Date: Sun, 01 Nov 2015 01:35:53 +0200 In-Reply-To: <20151029232302.GB3812@acm.fritz.box> (Alan Mackenzie's message of "Thu, 29 Oct 2015 23:23:02 +0000") Message-ID: <87h9l6627a.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > If Follow Mode is not enabled, all the above functions do the Right > Thing on the single window. >From another perspective, settings lazy-highlight-buffer to t (implemented in bug#21092) and removing the current restriction of (overlay-put ov 'window (selected-window)) will lazy-highlight matches in all follow windows with no effort. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 31 19:41:07 2015 Received: (at 17453) by debbugs.gnu.org; 31 Oct 2015 23:41:07 +0000 Received: from localhost ([127.0.0.1]:47388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zsflj-0002pw-6E for submit@debbugs.gnu.org; Sat, 31 Oct 2015 19:41:07 -0400 Received: from mail-pa0-f47.google.com ([209.85.220.47]:36299) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zsflg-0002po-TB for 17453@debbugs.gnu.org; Sat, 31 Oct 2015 19:41:05 -0400 Received: by pacfv9 with SMTP id fv9so113590599pac.3 for <17453@debbugs.gnu.org>; Sat, 31 Oct 2015 16:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:in-reply-to:date:organization:message-id :references:user-agent:mail-followup-to:mime-version:content-type; bh=lwHDdFPbPm/+o8a5dacSA4V3xjDbHv9HBQvtlFcQOi4=; b=lRnXpX9FAXrIqLdHOn98gIjwYvdOgNWwGc3SN5MNlCjSdf1GJIrhNTNm2/FnUCNtdU jR1oe43Zl76nkEge6kJQm60+REeUTsUv0HLIYkoq7CK50DYDmexu7zczuoIUAuQLr7sJ MtjyLD7KlojHLQUauYXKqkqbZHiUFPEGMEnZS343ScQS0YffNp4ENs3/EuSoqCLqSB3l Q06xgeE3AKNjb/WVdksE+ow64FkJEZ6sDlqtbdG43W30OHCQQUj+WuXFQ0rBTDZBtY80 kbugQQryralqvz/j79+N36TwQnqVKjXsI4DL4kedwzPisyD2ROtDvmcGIsDTk6vOfZnK eIZA== X-Received: by 10.66.189.68 with SMTP id gg4mr17720369pac.6.1446334864257; Sat, 31 Oct 2015 16:41:04 -0700 (PDT) Received: from Vulcan.attlocal.net (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id k10sm15750420pbq.78.2015.10.31.16.41.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 31 Oct 2015 16:41:03 -0700 (PDT) Received: by Vulcan.attlocal.net (Postfix, from userid 501) id 0B1721022D241; Sat, 31 Oct 2015 16:41:03 -0700 (PDT) From: "John Wiegley" To: Alan Mackenzie Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. In-Reply-To: <20151031232538.GC1853@acm.fritz.box> (Alan Mackenzie's message of "Sat, 31 Oct 2015 23:25:38 +0000") Date: Sat, 31 Oct 2015 16:41:01 -0700 Organization: New Artisans LLC Message-ID: References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <20151031232538.GC1853@acm.fritz.box> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Mail-Followup-To: Alan Mackenzie , Stefan Monnier , 17453@debbugs.gnu.org, emacs-devel@gnu.org MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >>>>> Alan Mackenzie writes: > What I am proposing now is a solution where any library which needs to > manipulate things like window positions will be trivially upgradable to > working with Follow Mode, merely by replacing `window-start' by > `window*-start', etc. Ah, I see. How many libraries do you think would need this change? Would using window-start become bad practice under this regime? John From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 31 19:55:25 2015 Received: (at 17453) by debbugs.gnu.org; 31 Oct 2015 23:55:25 +0000 Received: from localhost ([127.0.0.1]:47392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZsfzY-0003Ab-M1 for submit@debbugs.gnu.org; Sat, 31 Oct 2015 19:55:24 -0400 Received: from mail.muc.de ([193.149.48.3]:30181) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZsfzE-0003A9-R3 for 17453@debbugs.gnu.org; Sat, 31 Oct 2015 19:55:23 -0400 Received: (qmail 98697 invoked by uid 3782); 31 Oct 2015 23:55:03 -0000 Received: from acm.muc.de (p579E9C22.dip0.t-ipconnect.de [87.158.156.34]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 01 Nov 2015 00:55:03 +0100 Received: (qmail 26527 invoked by uid 1000); 31 Oct 2015 23:56:51 -0000 Date: Sat, 31 Oct 2015 23:56:51 +0000 To: Juri Linkov Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151031235651.GE1853@acm.fritz.box> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h9l6627a.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Juri. On Sun, Nov 01, 2015 at 01:35:53AM +0200, Juri Linkov wrote: > > If Follow Mode is not enabled, all the above functions do the Right > > Thing on the single window. > >>From another perspective, settings lazy-highlight-buffer to t > (implemented in bug#21092) and removing the current restriction of > (overlay-put ov 'window (selected-window)) will lazy-highlight matches > in all follow windows with no effort. I wasn't actually aware of that fix. There were three main problems my patch fixed: 1) Searching commands were restricted to a single follow window. This was caused by the lazy highlighting mechanism, as you say. 2) Lazy highlighting was only being done in a single window. 3) In scrolling commands, point was restricted to the singled window, rather than being able to move freely throughout all the windows. There were also some subtle things which could go wrong, in particular when the current isearch match spans two windows, and the next command causes the echo area to expand a line. This caused spurious scrolling of the windows. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 31 20:18:07 2015 Received: (at 17453) by debbugs.gnu.org; 1 Nov 2015 00:18:07 +0000 Received: from localhost ([127.0.0.1]:47399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZsgLX-0003iv-4i for submit@debbugs.gnu.org; Sat, 31 Oct 2015 20:18:07 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:49527) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZsgLB-0003i6-Sm for 17453@debbugs.gnu.org; Sat, 31 Oct 2015 20:18:04 -0400 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tA10HiBY016815 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 1 Nov 2015 00:17:44 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tA10Hhr5024609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 1 Nov 2015 00:17:43 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tA10HgQi024687; Sun, 1 Nov 2015 00:17:42 GMT MIME-Version: 1.0 Message-ID: Date: Sat, 31 Oct 2015 17:17:41 -0700 (PDT) From: Drew Adams To: John Wiegley , Alan Mackenzie Subject: RE: bug#17453: Isearch doesn't work properly with Follow Mode. References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) It's really not great when people cross-post a bug thread to emacs-devel (or vice versa). It can sometimes be appropriate to post a message to one or the other that references the other, to make people aware of the thread in the other list. And it can sometimes be appropriate to move a discussion from one list to the other. But this needless multiplication is a bother. (And yes, I've left both lists in this message to both.) From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 01 06:58:01 2015 Received: (at 17453) by debbugs.gnu.org; 1 Nov 2015 11:58:01 +0000 Received: from localhost ([127.0.0.1]:47531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZsrGr-0003oP-5X for submit@debbugs.gnu.org; Sun, 01 Nov 2015 06:58:01 -0500 Received: from mail.muc.de ([193.149.48.3]:59770) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZsrGW-0003nv-MM for 17453@debbugs.gnu.org; Sun, 01 Nov 2015 06:57:59 -0500 Received: (qmail 91858 invoked by uid 3782); 1 Nov 2015 11:57:39 -0000 Received: from acm.muc.de (p548A4E61.dip0.t-ipconnect.de [84.138.78.97]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 01 Nov 2015 12:57:38 +0100 Received: (qmail 2867 invoked by uid 1000); 1 Nov 2015 11:59:26 -0000 Date: Sun, 1 Nov 2015 11:59:26 +0000 To: Stefan Monnier , 17453@debbugs.gnu.org, emacs-devel@gnu.org Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151101115926.GA2768@acm.fritz.box> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <20151031232538.GC1853@acm.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, John. On Sat, Oct 31, 2015 at 04:41:01PM -0700, John Wiegley wrote: > >>>>> Alan Mackenzie writes: > > What I am proposing now is a solution where any library which needs to > > manipulate things like window positions will be trivially upgradable to > > working with Follow Mode, merely by replacing `window-start' by > > `window*-start', etc. > Ah, I see. How many libraries do you think would need this change? I honestly don't know. At a guess, I'd say several rather than many. As a quick benchmark, there are 127 occurrences of set-window-start in our lisp sources, in 59 files. > Would using window-start become bad practice under this regime? I hadn't actually thought of that. Thinking about set-window-start (rather than simply window-start), there will be lots of places where a mode is explicitly handling its own windows (? speedbar.el, for example), and set-window*-start would be the wrong thing. But there are also surely examples where set-window-start is currently used just to scroll the text to a specific position. Here set-window*-start would be better. > John -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 01 07:20:41 2015 Received: (at 17453) by debbugs.gnu.org; 1 Nov 2015 12:20:41 +0000 Received: from localhost ([127.0.0.1]:47543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zsrcm-0004L2-NR for submit@debbugs.gnu.org; Sun, 01 Nov 2015 07:20:40 -0500 Received: from mail-lb0-f178.google.com ([209.85.217.178]:34182) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZsrcS-0004KT-RO for 17453@debbugs.gnu.org; Sun, 01 Nov 2015 07:20:39 -0500 Received: by lbbwb3 with SMTP id wb3so72360861lbb.1 for <17453@debbugs.gnu.org>; Sun, 01 Nov 2015 04:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=oqqDsOw06OF26PadytXOHq3Ey9yelWIirs7YiAkzHLE=; b=wwkjsnaXNauNVwLz0QXPMJNHVu9mpoleEr25rgIv3nHXPOpmUIAB8x1W3MAf4PfHJh BdspcvZxpxSqGV1cfd2C4h+O+GGdjRUSI1rQG5duPGYkPfeFuTToZmiCDo4FGESDBibr Gx++wkmygI8hwajieZgSkXNR4JQ/Oami0veQr1qSPZpmEd7dZM5sREOadxzdjbBVs4GY XXTzkW6sG7DSVnYPcGLBYnYPvmTHZV5dClptOrUM9XzPK8EyZ3wImVPXOBxQz8U5035D SBc5ab97XiH0qrIhA0F0m9YEsStRguK61gTqAzTWR2NQxMjke4KxAY3rh8fhtviCqA5o d7oQ== MIME-Version: 1.0 X-Received: by 10.112.135.233 with SMTP id pv9mr7928300lbb.42.1446380419986; Sun, 01 Nov 2015 04:20:19 -0800 (PST) Received: by 10.112.63.71 with HTTP; Sun, 1 Nov 2015 04:20:19 -0800 (PST) In-Reply-To: <20151031233225.GD1853@acm.fritz.box> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <20151031233225.GD1853@acm.fritz.box> Date: Sun, 1 Nov 2015 12:20:19 +0000 X-Google-Sender-Auth: 9stkvly6kqbCFWCvQSSMYE76v24 Message-ID: Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. From: Artur Malabarba To: Alan Mackenzie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bruce.connor.am@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hi Alan, >> What if isearch just took into account all windows displaying >> current-buffer, instead of just the selected one? >> This wouldn=E2=80=99t involve anything specific to follow mode, and I be= lieve it >> would solve the issue, no? > > I don't think so, really. What exactly does "took into account" mean? > With Follow Mode active, on a forward search you explicitly want point to > move into the next window when the search target is visible there. When > FM is not active, you most definitely don't want this to happen. Well, one of the reasons I suggested it is because I think I actually would want that. But, of course, it would be conditioned on a variable (disabled by default), and follow-mode would simply have to enable it. > I have working code which make isearch and FM work together nicely. I > think it's a sufficiently "nice" implementation to commit. Sure. Don't take this as me trying to push you in a different direction. I brought it up because it sounded like it would be simpler. You have a better understanding of the issue and the code than I do, don't feel obliged to try my suggestion. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 01 07:23:55 2015 Received: (at 17453) by debbugs.gnu.org; 1 Nov 2015 12:23:55 +0000 Received: from localhost ([127.0.0.1]:47547 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zsrfv-0004Pv-8l for submit@debbugs.gnu.org; Sun, 01 Nov 2015 07:23:55 -0500 Received: from mail-lb0-f181.google.com ([209.85.217.181]:33155) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zsrft-0004Pn-6M for 17453@debbugs.gnu.org; Sun, 01 Nov 2015 07:23:53 -0500 Received: by lbbec13 with SMTP id ec13so73229354lbb.0 for <17453@debbugs.gnu.org>; Sun, 01 Nov 2015 04:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aSzSZ7rUZOUbsTmoHG5vsOyT+j4ctRwR83WnF1HBJrI=; b=SvhZnTAiz60FfRTlpYkTmeN147gf4ui0Tig+M5FpnwhHXlw4zm1y1MThEnIbz1bMyp a8RjESBQtA4VcmAJL8BhFmhbmwkCShucqPnmjYKubTX5B/zXWZUPusqIv4AwHk7GE3Rw 95nleBJeK8ukItfoHZiHqVOBe6u/ASjSUTkJyra4wSVf9EVKzS/RiMGVQJXrPZ9T8Ift X6zQdV8IfjH0mAfuNEMELi0YSwAIYcYWgTOviS0dl9Yz7SCVUMaD5lUd7tjQRfucDQ4y cqoK1zCZEPb614xe8cnqtOFg01GuuHE875yS7BbEtmC2yXU0Nklvym0ihQYI5SjjainG /OOw== MIME-Version: 1.0 X-Received: by 10.112.35.196 with SMTP id k4mr7775315lbj.3.1446380632386; Sun, 01 Nov 2015 04:23:52 -0800 (PST) Received: by 10.112.63.71 with HTTP; Sun, 1 Nov 2015 04:23:52 -0800 (PST) In-Reply-To: References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <20151031233225.GD1853@acm.fritz.box> Date: Sun, 1 Nov 2015 12:23:52 +0000 X-Google-Sender-Auth: 4efB_VnSCCM2QK2sQnh4p7lYNxc Message-ID: Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. From: Artur Malabarba To: Alan Mackenzie Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bruce.connor.am@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 2015-11-01 12:20 GMT+00:00 Artur Malabarba : > You have a better understanding of the issue and the code than I do, > don't feel obliged to try my suggestion. Anyway, could we see this code? :-) Can you send it as patch or push it to a scratch/window-groups branch? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 01 19:16:05 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 00:16:05 +0000 Received: from localhost ([127.0.0.1]:48222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zt2n7-0002QR-0g for submit@debbugs.gnu.org; Sun, 01 Nov 2015 19:16:05 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:46317 helo=homiemail-a100.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zt2mn-0002Pf-6V for 17453@debbugs.gnu.org; Sun, 01 Nov 2015 19:16:04 -0500 Received: from homiemail-a100.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTP id 4596231A073; Sun, 1 Nov 2015 16:15:44 -0800 (PST) Received: from localhost.linkov.net (82.131.11.41.cable.starman.ee [82.131.11.41]) (Authenticated sender: jurta@jurta.org) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTPA id 0160131A070; Sun, 1 Nov 2015 16:15:42 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Organization: LINKOV.NET References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> Date: Mon, 02 Nov 2015 02:14:47 +0200 In-Reply-To: <20151031235651.GE1853@acm.fritz.box> (Alan Mackenzie's message of "Sat, 31 Oct 2015 23:56:51 +0000") Message-ID: <87bnbddzpk.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> >>From another perspective, settings lazy-highlight-buffer to t >> (implemented in bug#21092) and removing the current restriction of >> (overlay-put ov 'window (selected-window)) will lazy-highlight matches >> in all follow windows with no effort. > > I wasn't actually aware of that fix. > > There were three main problems my patch fixed: > 1) Searching commands were restricted to a single follow window. This > was caused by the lazy highlighting mechanism, as you say. > 2) Lazy highlighting was only being done in a single window. > 3) In scrolling commands, point was restricted to the singled window, > rather than being able to move freely throughout all the windows. IIUC, lazy highlighting is not a problem anymore, so the remaining problem is how to switch windows when the next search position happens to be in an adjacent window. Since there is no other core library that require so much changes to adapt to follow-mode, and there are already some mode-specific hooks in follow.el like compilation-filter-hook, indicates that it's the responsibility of follow.el to support isearch in follow-mode. So I believe the right way to do this is like Artur presented in a short patch, and maybe it's possible to simplify it even more by using isearch-update-post-hook with a follow-align-compilation-windows like hook. I mean something like (add-hook 'isearch-update-post-hook follow-align-isearch-windows t t) From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 01 22:35:41 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 03:35:41 +0000 Received: from localhost ([127.0.0.1]:48308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zt5uF-000282-V1 for submit@debbugs.gnu.org; Sun, 01 Nov 2015 22:35:40 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:48573) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zt5tu-00027a-F0 for 17453@debbugs.gnu.org; Sun, 01 Nov 2015 22:35:38 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NX6003004RZ0D00@mtaout26.012.net.il> for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 05:38:45 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NX600H6Q4SLQI90@mtaout26.012.net.il>; Mon, 02 Nov 2015 05:38:45 +0200 (IST) Date: Mon, 02 Nov 2015 05:35:27 +0200 From: Eli Zaretskii Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. In-reply-to: <87bnbddzpk.fsf@mail.linkov.net> X-012-Sender: halo1@inter.net.il To: Juri Linkov Message-id: <837fm1xedc.fsf@gnu.org> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17453 Cc: acm@muc.de, 17453@debbugs.gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Juri Linkov > Date: Mon, 02 Nov 2015 02:14:47 +0200 > Cc: 17453@debbugs.gnu.org, Stefan Monnier , > emacs-devel@gnu.org > > Since there is no other core library that require so much changes to > adapt to follow-mode, and there are already some mode-specific hooks > in follow.el like compilation-filter-hook, indicates that it's the > responsibility of follow.el to support isearch in follow-mode. So I > believe the right way to do this is like Artur presented in a short > patch, and maybe it's possible to simplify it even more by using > isearch-update-post-hook with a follow-align-compilation-windows > like hook. I mean something like (add-hook > 'isearch-update-post-hook follow-align-isearch-windows t t) I agree. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 04:27:09 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 09:27:09 +0000 Received: from localhost ([127.0.0.1]:48499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtBOO-0003y2-V9 for submit@debbugs.gnu.org; Mon, 02 Nov 2015 04:27:09 -0500 Received: from mail.muc.de ([193.149.48.3]:22319) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtBOM-0003xs-TA for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 04:27:07 -0500 Received: (qmail 19931 invoked by uid 3782); 2 Nov 2015 09:27:05 -0000 Received: from acm.muc.de (p5B147B71.dip0.t-ipconnect.de [91.20.123.113]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 02 Nov 2015 10:27:04 +0100 Received: (qmail 12003 invoked by uid 1000); 2 Nov 2015 09:28:53 -0000 Date: Mon, 2 Nov 2015 09:28:53 +0000 To: Juri Linkov Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151102092853.GA11804@acm.fritz.box> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bnbddzpk.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hi, Juri. On Mon, Nov 02, 2015 at 02:14:47AM +0200, Juri Linkov wrote: > >> >>From another perspective, settings lazy-highlight-buffer to t > >> (implemented in bug#21092) and removing the current restriction of > >> (overlay-put ov 'window (selected-window)) will lazy-highlight matches > >> in all follow windows with no effort. > > I wasn't actually aware of that fix. > > There were three main problems my patch fixed: > > 1) Searching commands were restricted to a single follow window. This > > was caused by the lazy highlighting mechanism, as you say. > > 2) Lazy highlighting was only being done in a single window. > > 3) In scrolling commands, point was restricted to the singled window, > > rather than being able to move freely throughout all the windows. > IIUC, lazy highlighting is not a problem anymore, .... It is. With Follow Mode enabled, lazy highlighting is only occurring in the one window, not all of them. > .... so the remaining problem is how to switch windows when the next > search position happens to be in an adjacent window. That problem only shows itself when lazy-highlighting is enabled. This suggests that the solution is to fix the lazy-highliting code so as not to mess up the window arrangement. The other problem which still exists is that when isearch-allow-scroll is enabled, point cannot be scrolled into a neighbouring Follow Mode window. > Since there is no other core library that require so much changes to > adapt to follow-mode, .... I don't think we know this. > .... and there are already some mode-specific hooks in follow.el like > compilation-filter-hook, indicates that it's the responsibility of > follow.el to support isearch in follow-mode. There is nothing Follow Mode can do about isearch restricting its lazy-highlighting and bounds for scrolling to one single window. Isearch itself must be adapted for Follow Mode to work with it. > So I believe the right way to do this is like Artur presented in a > short patch, .... I don't actually understand that patch, I'll need to study the wierd/new constructs used in it, like `when-let'. However, I'm certain that that patch will not fix all the problems discussed in this post. One way or another, isearch MUST work with the window boundaries of the entire Follow Mode group. > .... and maybe it's possible to simplify it even more by using > isearch-update-post-hook with a follow-align-compilation-windows like > hook. I mean something like (add-hook 'isearch-update-post-hook > follow-align-isearch-windows t t) Hmm. I see that more as complicatifying rather than simplifying. The imperative, set out by Stefan 18 months ago, was to keep internal Follow Mode stuff out of isearch. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 06:53:14 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 11:53:14 +0000 Received: from localhost ([127.0.0.1]:48557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtDfl-0007UY-Fz for submit@debbugs.gnu.org; Mon, 02 Nov 2015 06:53:13 -0500 Received: from mail-lb0-f169.google.com ([209.85.217.169]:35573) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtDfj-0007UN-DS for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 06:53:12 -0500 Received: by lbbes7 with SMTP id es7so86160112lbb.2 for <17453@debbugs.gnu.org>; Mon, 02 Nov 2015 03:53:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=oyBG3iZQdJZxU1JJi9YqCIvO+A39dlROTAkwOCJ5cAI=; b=sf/r6vJ0riO6FmHVTL43ullPPcCiSe/vXkSYmOWaHgrWogdj4mBFgtrCKu9aW/9Q8I xt1FDE8tOH454R7GnZOqM8RkzpFLiRJYjCl09O8XWZsRIT7z3QAwMr2WNSamoQSY/6P/ g9Ju6+4B9yXS7ANlvBsWdGZExfyp/gQqeRkmKgmcg8KIM0d7AbEGCfWIUDzLcdHYTYbJ ZWvBjtGwsS9fwQUOBNtIIp9UN07l+r0uhtCg+OClVkD0XhXr3w/M4ttJ+1UJ0IHwXeDH Qmq0S3anuNytGDQXwio65GfUuHHIxN6lp9dqyDlsztU7/5wkxVBttFATOfLDNmCpTd4l hjlA== MIME-Version: 1.0 X-Received: by 10.112.157.105 with SMTP id wl9mr3991726lbb.2.1446465190399; Mon, 02 Nov 2015 03:53:10 -0800 (PST) Received: by 10.112.63.71 with HTTP; Mon, 2 Nov 2015 03:53:10 -0800 (PST) In-Reply-To: <20151102092853.GA11804@acm.fritz.box> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> Date: Mon, 2 Nov 2015 11:53:10 +0000 X-Google-Sender-Auth: t6Cj2BwaavhWlnK5vHXFfpzw1DA Message-ID: Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. From: Artur Malabarba To: Alan Mackenzie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, emacs-devel , Stefan Monnier , Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bruce.connor.am@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > I don't actually understand that patch, I'll need to study the wierd/new > constructs used in it, like `when-let'. Here's a more thoroughly explained version of this function, that doesn't use when-let. seq-find is equivalent to cl-find-if, it returns the first element that matches the provided predicate. (defun follow--search-function () (lambda (&rest args) (let ((search-function (isearch-search-fun-default)) (matched (apply search-function args))) ;; If this is a proper user-triggered search (and not just a ;; lazy-highlight search), and if the search matched, and if the ;; match is not visible on this window... (when (and matched (not isearch-lazy-highlight-ongoing-search) (not (and (pos-visible-in-window-p (match-beginning 0)) (pos-visible-in-window-p (match-end 0))))) ;; ... see if the match is visible on another window. (let ((win (seq-find (lambda (w) (and (pos-visible-in-window-p (match-beginning 0) w) (pos-visible-in-window-p (match-end 0) = w))) (follow-all-followers)))) ;; If so, select it. (when win (select-window win)))) matched))) I also changed it to use (follow-all-followers). > However, I'm certain that that patch will not fix all the problems > discussed in this post. The patch as provided doesn't fix the =E2=80=9Chighlighting matches on all windows=E2=80=9D issue. But that's trivial to solve by removing that `(overlay-put ov 'window (selected-window))' line. (which I have half a mind to do right now because I just think it's a generally useful improvement.) > One way or another, isearch MUST work with the > window boundaries of the entire Follow Mode group. Maybe I missed part of the issue. I thought you wanted Isearch to switch to another window if that window contains the next match (instead of scrolling the current window). For that, you only need pos-visible-in-window-p, you don't need to mess with boundaries. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 07:14:14 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 12:14:14 +0000 Received: from localhost ([127.0.0.1]:48568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtE06-00080y-7D for submit@debbugs.gnu.org; Mon, 02 Nov 2015 07:14:14 -0500 Received: from mail-lf0-f48.google.com ([209.85.215.48]:34343) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtE04-00080q-So for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 07:14:13 -0500 Received: by lfgh9 with SMTP id h9so14034719lfg.1 for <17453@debbugs.gnu.org>; Mon, 02 Nov 2015 04:14:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=igI1WpOBbAW4fV3eE5R97OrLOWwZrn+wiwVos9eT/RY=; b=cv7cK4l5bjRA5zuEVsH2WPI9H1i+9UcIWIa6tL8ApkjYUfXczQH41fXA2LXT9CeZaU fNKVqsGD1YPrj5PIvEIYUCEUqJa9EpUht5FI5RFcm0cnVrefr6zPzwofl1NwrVXiqy7q TuONpltlPOLwb+vsSd1G6QPh5RaPmMH+8+9p1qCzmV9hrnfC4mBGAPWAOG8eT08EkBF9 qcnZiuqUpEDt18O3p5kuMgAhRp7TjNjUHOWTKkPK+8l7hxdfrcEBxlHJL/hcaUH4s9sv HKr5j2qbZYjEIzW5WEXbibqpby51uef1WsbmTxj0WBsK6Yrzk1u2dhgx7ZjAoQCHjhKp ty0A== MIME-Version: 1.0 X-Received: by 10.25.85.193 with SMTP id j184mr6305211lfb.2.1446466452200; Mon, 02 Nov 2015 04:14:12 -0800 (PST) Received: by 10.112.63.71 with HTTP; Mon, 2 Nov 2015 04:14:12 -0800 (PST) In-Reply-To: References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> Date: Mon, 2 Nov 2015 12:14:12 +0000 X-Google-Sender-Auth: VOcFk2oYpKgM1Dsa8DNFN5oWjzQ Message-ID: Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. From: Artur Malabarba To: Alan Mackenzie Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, emacs-devel , Stefan Monnier , Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bruce.connor.am@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> One way or another, isearch MUST work with the >> window boundaries of the entire Follow Mode group. > > Maybe I missed part of the issue. I thought you wanted Isearch to > switch to another window if that window contains the next match > (instead of scrolling the current window). For that, you only need > pos-visible-in-window-p, you don't need to mess with boundaries. I think I see what I'm missing. Lazy-highlighting stops at the end of the window, so the matches on the second window won't be highlighted until we switch to it, right? From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 07:33:33 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 12:33:33 +0000 Received: from localhost ([127.0.0.1]:48574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtEIn-0001ds-7P for submit@debbugs.gnu.org; Mon, 02 Nov 2015 07:33:33 -0500 Received: from mail.muc.de ([193.149.48.3]:55832) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtEIl-0001dj-0s for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 07:33:31 -0500 Received: (qmail 61886 invoked by uid 3782); 2 Nov 2015 12:33:29 -0000 Received: from acm.muc.de (p5B147B71.dip0.t-ipconnect.de [91.20.123.113]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 02 Nov 2015 13:33:28 +0100 Received: (qmail 13512 invoked by uid 1000); 2 Nov 2015 12:35:12 -0000 Date: Mon, 2 Nov 2015 12:35:12 +0000 To: Artur Malabarba Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151102123512.GB11804@acm.fritz.box> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: Juri Linkov , 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Artur. On Mon, Nov 02, 2015 at 11:53:10AM +0000, Artur Malabarba wrote: > > I don't actually understand that patch, I'll need to study the wierd/new > > constructs used in it, like `when-let'. > Here's a more thoroughly explained version of this function, that > doesn't use when-let. > seq-find is equivalent to cl-find-if, it returns the first element > that matches the provided predicate. OK. [ .... ] > I also changed it to use (follow-all-followers). That's unwanted. ;-) Isearch should not be using internal Follow Mode functions. Some more abstraction would be needed. > > However, I'm certain that that patch will not fix all the problems > > discussed in this post. > The patch as provided doesn't fix the “highlighting matches on all > windows” issue. But that's trivial to solve by removing that > `(overlay-put ov 'window (selected-window))' line. (which I have half > a mind to do right now because I just think it's a generally useful > improvement.) Lazy highlighting searches for matches on the current window. It must be extended to search for matches on the Follow Mode group of windows. For that, it needs the details of the "window*-start" and "window*-end". > > One way or another, isearch MUST work with the > > window boundaries of the entire Follow Mode group. > Maybe I missed part of the issue. I thought you wanted Isearch to > switch to another window if that window contains the next match > (instead of scrolling the current window). For that, you only need > pos-visible-in-window-p, you don't need to mess with boundaries. What is causing the unwanted scrolling rather than moving to the next window, is the form "(sit-for 0)" near the start of isearch-lazy-highlight-new-loop. When point is outside the window, this form causes redisplay, which scrolls point back into the window - without Follow Mode getting a look in. In my patch, I replaced this with "(sit*-for 0)", where Follow Mode can do its thing before the redisplay happens. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 07:38:04 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 12:38:04 +0000 Received: from localhost ([127.0.0.1]:48578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtENA-0001kv-33 for submit@debbugs.gnu.org; Mon, 02 Nov 2015 07:38:04 -0500 Received: from mail.muc.de ([193.149.48.3]:19736) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtEN8-0001kl-NL for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 07:38:03 -0500 Received: (qmail 62896 invoked by uid 3782); 2 Nov 2015 12:38:02 -0000 Received: from acm.muc.de (p5B147B71.dip0.t-ipconnect.de [91.20.123.113]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 02 Nov 2015 13:38:00 +0100 Received: (qmail 13545 invoked by uid 1000); 2 Nov 2015 12:39:49 -0000 Date: Mon, 2 Nov 2015 12:39:49 +0000 To: Artur Malabarba Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151102123949.GC11804@acm.fritz.box> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: Juri Linkov , 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Artur. On Mon, Nov 02, 2015 at 12:14:12PM +0000, Artur Malabarba wrote: > >> One way or another, isearch MUST work with the > >> window boundaries of the entire Follow Mode group. > > Maybe I missed part of the issue. I thought you wanted Isearch to > > switch to another window if that window contains the next match > > (instead of scrolling the current window). For that, you only need > > pos-visible-in-window-p, you don't need to mess with boundaries. > I think I see what I'm missing. Lazy-highlighting stops at the end of > the window, so the matches on the second window won't be highlighted > until we switch to it, right? Absolutely! Not forgetting, of course, matches which start near the bottom of one window, and carry on at the top of the next window. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 08:10:46 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 13:10:46 +0000 Received: from localhost ([127.0.0.1]:48599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtEsn-0002ba-9r for submit@debbugs.gnu.org; Mon, 02 Nov 2015 08:10:45 -0500 Received: from mail-lf0-f42.google.com ([209.85.215.42]:34973) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtEsT-0002b2-Mo for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 08:10:44 -0500 Received: by lfbn126 with SMTP id n126so61128783lfb.2 for <17453@debbugs.gnu.org>; Mon, 02 Nov 2015 05:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8CMmOGobFtzLYt+zVxfd4D6sW5ld/JqJvL1hP+CCXGU=; b=gyWOE7eom1Ub0VMJsugE41jqJkaIiU4Kgf2BENMsxWgAt66RXgpn+BRY2I556xKFfu nBn8JerHoAmxUK7QH3eiXqALosqRQ7TGKMrDgF4ZTPdN2jbnfG0RmDEYx2dSXbPw8obw Fn8aQX6x7AH+loU+fIJjtqmiYylOK/grHlkPlK8ns1Z3L3kCXvdsZfnlK7CqxZKqiXAt KDRl86YVX8aNcztLb2tDhyF5ZDxeTL1/fDQ1JaRvaiQGkql0WJzQorGfV1TE72+JKIke QHwbPobreMwy4v7m1C2UuJIzXe58BS7tsPOoIuWuzv+oQAIkqiUIamys9MUD8iLLwKq3 gYiw== MIME-Version: 1.0 X-Received: by 10.25.141.77 with SMTP id p74mr6628448lfd.17.1446469824753; Mon, 02 Nov 2015 05:10:24 -0800 (PST) Received: by 10.112.63.71 with HTTP; Mon, 2 Nov 2015 05:10:24 -0800 (PST) In-Reply-To: <20151102123512.GB11804@acm.fritz.box> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> Date: Mon, 2 Nov 2015 13:10:24 +0000 X-Google-Sender-Auth: eOsBpHKS6KjNyu_p-6B55JNo4tk Message-ID: Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. From: Artur Malabarba To: Alan Mackenzie Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: Juri Linkov , 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bruce.connor.am@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> I also changed it to use (follow-all-followers). > > That's unwanted. ;-) Isearch should not be using internal Follow Mode > functions. Some more abstraction would be needed. That function goes in follow.el. ;-) > Lazy highlighting searches for matches on the current window. It must > be extended to search for matches on the Follow Mode group of windows. > For that, it needs the details of the "window*-start" and "window*-end". Yes, you're right, I see that now. This might still be solvable via setting isearch-search-fun-function, I'll need to think on that for a moment. I see nothing wrong with the window*-start/end functionality you suggest, but if we can solve this problem via configuration points that are already provided (like isearch-search-fun-function) then all the better. >> > One way or another, isearch MUST work with the >> > window boundaries of the entire Follow Mode group. > >> Maybe I missed part of the issue. I thought you wanted Isearch to >> switch to another window if that window contains the next match >> (instead of scrolling the current window). For that, you only need >> pos-visible-in-window-p, you don't need to mess with boundaries. > > What is causing the unwanted scrolling rather than moving to the next > window, is the form "(sit-for 0)" near the start of > isearch-lazy-highlight-new-loop. I think the patch I provided switches to the second (or third or whatever) window before that sit-for runs. So I believe it solves this problem. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 09:19:23 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 14:19:23 +0000 Received: from localhost ([127.0.0.1]:48640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtFxC-0004V7-N0 for submit@debbugs.gnu.org; Mon, 02 Nov 2015 09:19:23 -0500 Received: from mail-lb0-f169.google.com ([209.85.217.169]:34254) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtFwr-0004UL-64 for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 09:19:20 -0500 Received: by lbbwb3 with SMTP id wb3so88847233lbb.1 for <17453@debbugs.gnu.org>; Mon, 02 Nov 2015 06:19:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=IlZnzSHb377Cqvqxh7YyKWjq887wBO6VilqxzWcroaE=; b=ZrduM0W5kwMfOdA5dFBePA8Lzm+jdvAKxLXgih9XEXWtX6mvDsiHpnspI0pFwBUHsc G9G1IvPtjvEk24hkktGHqCFtH7gwPl6qMZxio9lPlGW7iEqZmngsyxPzfYl2V4iH7HGu TpMMzzpXO/ZFbddXQ5T+nWxhC+CqXFJhCXC7nS1PUQD1yd0B8GQq6xEiupb9diywf4Wz 1t7Ts3jKSfgRZwYETgdbbPALcyp1yLTzDyW5MOHeJ07HsGPugUUd9mxp4EkPaCwcRaoi jPDVRoKyghkrOb68Qmxgy8IR1TMKVl1b1kdk9/+YH+hM76P0iVdaUG61NR3oFxPehont a4oQ== MIME-Version: 1.0 X-Received: by 10.112.235.65 with SMTP id uk1mr9909734lbc.118.1446473940167; Mon, 02 Nov 2015 06:19:00 -0800 (PST) Received: by 10.112.63.71 with HTTP; Mon, 2 Nov 2015 06:18:59 -0800 (PST) In-Reply-To: References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> Date: Mon, 2 Nov 2015 14:18:59 +0000 X-Google-Sender-Auth: YDhDSxLudc0oQsem0_l_Aosg-18 Message-ID: Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. From: Artur Malabarba To: Alan Mackenzie Content-Type: multipart/mixed; boundary=001a11c310be622b2405238f7547 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: Juri Linkov , 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bruce.connor.am@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c310be622b2405238f7547 Content-Type: text/plain; charset=UTF-8 > > Lazy highlighting searches for matches on the current window. It must > > be extended to search for matches on the Follow Mode group of windows. > > For that, it needs the details of the "window*-start" and "window*-end". > > Yes, you're right, I see that now. This might still be solvable via > setting isearch-search-fun-function, I'll need to think on that for a > moment. Here's a new version, split into 3 short patches to make it easier to understand. This makes 2 small changes to isearch (which I think are even justifiable on their own, regardless of follow-mode), and defines a new function in follow-mode which takes care of two things: Matches are highlighted on all windows When the user types something, and the next match is on another window, switch to that window instead of scrolling the current one. --001a11c310be622b2405238f7547 Content-Type: text/x-patch; charset=US-ASCII; name="0003-lisp-follow.el-Improve-isearch-compatibility.patch" Content-Disposition: attachment; filename="0003-lisp-follow.el-Improve-isearch-compatibility.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_igi180vy0 RnJvbSBjYWY1YWRmYzBiN2NhZjA3ZGM3NDgxMzI0MmY5ZWNjNjY0YmFiYzEzIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBcnR1ciBNYWxhYmFyYmEgPGJydWNlLmNvbm5vci5hbUBnbWFp bC5jb20+CkRhdGU6IE1vbiwgMiBOb3YgMjAxNSAxNDowMToxOCArMDAwMApTdWJqZWN0OiBbUEFU Q0ggMy8zXSAqIGxpc3AvZm9sbG93LmVsOiBJbXByb3ZlIGlzZWFyY2ggY29tcGF0aWJpbGl0eQoK KGZvbGxvdy0tc2VhcmNoLWZ1bmN0aW9uKTogTmV3IGZ1bmN0aW9uLgooZm9sbG93LW1vZGUpOiBD b25maWd1cmUgYGlzZWFyY2gtbGF6eS1oaWdobGlnaHQnIGFuZApgaXNlYXJjaC1zZWFyY2gtZnVu LWZ1bmN0aW9uJy4KLS0tCiBsaXNwL2ZvbGxvdy5lbCB8IDMzICsrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKwogMSBmaWxlIGNoYW5nZWQsIDMzIGluc2VydGlvbnMoKykKCmRpZmYgLS1n aXQgYS9saXNwL2ZvbGxvdy5lbCBiL2xpc3AvZm9sbG93LmVsCmluZGV4IDkzOGM1OWUuLjBiODBm MDQgMTAwNjQ0Ci0tLSBhL2xpc3AvZm9sbG93LmVsCisrKyBiL2xpc3AvZm9sbG93LmVsCkBAIC00 MTksNiArNDE5LDkgQEAgZm9sbG93LW1vZGUKICAgOmtleW1hcCBmb2xsb3ctbW9kZS1tYXAKICAg KGlmIGZvbGxvdy1tb2RlCiAgICAgICAocHJvZ24KKyAgICAgICAgKHNldHEtbG9jYWwgaXNlYXJj aC1zZWFyY2gtZnVuLWZ1bmN0aW9uICMnZm9sbG93LS1zZWFyY2gtZnVuY3Rpb24pCisgICAgICAg ICh3aGVuIGlzZWFyY2gtbGF6eS1oaWdobGlnaHQKKyAgICAgICAgICAoc2V0cS1sb2NhbCBpc2Vh cmNoLWxhenktaGlnaGxpZ2h0ICdhbGwtd2luZG93cykpCiAJKGFkZC1ob29rICdjb21waWxhdGlv bi1maWx0ZXItaG9vayAnZm9sbG93LWFsaWduLWNvbXBpbGF0aW9uLXdpbmRvd3MgdCB0KQogCShh ZGQtaG9vayAncG9zdC1jb21tYW5kLWhvb2sgJ2ZvbGxvdy1wb3N0LWNvbW1hbmQtaG9vayB0KQog CShhZGQtaG9vayAnd2luZG93LXNpemUtY2hhbmdlLWZ1bmN0aW9ucyAnZm9sbG93LXdpbmRvdy1z aXplLWNoYW5nZSB0KSkKQEAgLTQzNCw2ICs0MzcsMzYgQEAgZm9sbG93LW1vZGUKIAkocmVtb3Zl LWhvb2sgJ3dpbmRvdy1zaXplLWNoYW5nZS1mdW5jdGlvbnMgJ2ZvbGxvdy13aW5kb3ctc2l6ZS1j aGFuZ2UpKSkKICAgICAocmVtb3ZlLWhvb2sgJ2NvbXBpbGF0aW9uLWZpbHRlci1ob29rICdmb2xs b3ctYWxpZ24tY29tcGlsYXRpb24td2luZG93cyB0KSkpCiAKKyhkZWZ1biBmb2xsb3ctLXNlYXJj aC1mdW5jdGlvbiAoKQorICAiUmV0dXJuIGEgZnVuY3Rpb24gc3VpdGFibGUgZm9yIGBpc2VhcmNo LXNlYXJjaC1mdW4tZnVuY3Rpb24nLiIKKyAgKGxhbWJkYSAoc3RyaW5nICZvcHRpb25hbCBib3Vu ZCBub2Vycm9yIGNvdW50KQorICAgIChsZXQqICgoc2VhcmNoLWZ1bmN0aW9uIChpc2VhcmNoLXNl YXJjaC1mdW4tZGVmYXVsdCkpCisgICAgICAgICAgIChhbGwtZm9sbG93ZXJzIChmb2xsb3ctYWxs LWZvbGxvd2VycykpCisgICAgICAgICAgIDs7IElmIGJvdW5kIGF0IHRoZSBlZGdlIG9mIHRoZSB3 aW5kb3csIGV4dGVuZCBpdCB0byB0aGUKKyAgICAgICAgICAgOzsgZWRnZXMga25vdyBieSBgZm9s bG93LW1vZGUnLgorICAgICAgICAgICAoYm91bmQgKGNvbmQgKChlcXVhbCBib3VuZCAod2luZG93 LWVuZCkpCisgICAgICAgICAgICAgICAgICAgICAgICAgKHdpbmRvdy1lbmQgKGNhciAobGFzdCBh bGwtZm9sbG93ZXJzKSkpKQorICAgICAgICAgICAgICAgICAgICAgICAgKChlcXVhbCBib3VuZCAo d2luZG93LXN0YXJ0KSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAod2luZG93LXN0YXJ0IChj YXIgYWxsLWZvbGxvd2VycykpKQorICAgICAgICAgICAgICAgICAgICAgICAgKHQgYm91bmQpKSkK KyAgICAgICAgICAgKG1hdGNoZWQgKGZ1bmNhbGwgc2VhcmNoLWZ1bmN0aW9uIHN0cmluZyBib3Vu ZCBub2Vycm9yIGNvdW50KSkpCisgICAgICA7OyBJZiB0aGlzIGlzIGEgcHJvcGVyIHVzZXItdHJp Z2dlcmVkIHNlYXJjaCAoYW5kIG5vdCBqdXN0IGEKKyAgICAgIDs7IGxhenktaGlnaGxpZ2h0IHNl YXJjaCksIGFuZCBpZiB0aGUgc2VhcmNoIG1hdGNoZWQsIGFuZCBpZiB0aGUKKyAgICAgIDs7IG1h dGNoIGlzIG5vdCB2aXNpYmxlIG9uIHRoaXMgd2luZG93Li4uCisgICAgICAod2hlbiAoYW5kIG1h dGNoZWQKKyAgICAgICAgICAgICAgICAgKG5vdCBpc2VhcmNoLWxhenktaGlnaGxpZ2h0LW9uZ29p bmctc2VhcmNoKQorICAgICAgICAgICAgICAgICAobm90IChhbmQgKHBvcy12aXNpYmxlLWluLXdp bmRvdy1wIChtYXRjaC1iZWdpbm5pbmcgMCkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAo cG9zLXZpc2libGUtaW4td2luZG93LXAgKG1hdGNoLWVuZCAwKSkpKSkKKyAgICAgICAgOzsgLi4u IHNlZSBpZiB0aGUgbWF0Y2ggaXMgdmlzaWJsZSBvbiBhbm90aGVyIHdpbmRvdy4KKyAgICAgICAg KGxldCAoKHdpbiAoc2VxLWZpbmQgKGxhbWJkYSAodykKKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKGFuZCAocG9zLXZpc2libGUtaW4td2luZG93LXAgKG1hdGNoLWJlZ2lubmluZyAwKSB3 KQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChwb3MtdmlzaWJsZS1pbi13aW5k b3ctcCAobWF0Y2gtZW5kIDApIHcpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIGFsbC1m b2xsb3dlcnMpKSkKKyAgICAgICAgICA7OyBJZiBzbywgc2VsZWN0IGl0LgorICAgICAgICAgICh3 aGVuIHdpbgorICAgICAgICAgICAgKHNlbGVjdC13aW5kb3cgd2luKSkpKQorICAgICAgbWF0Y2hl ZCkpKQorCiAoZGVmdW4gZm9sbG93LWZpbmQtZmlsZS1ob29rICgpCiAgICJGaW5kLWZpbGUgaG9v ayBmb3IgRm9sbG93IG1vZGUuICBTZWUgdGhlIHZhcmlhYmxlIGBmb2xsb3ctYXV0bycuIgogICAo aWYgZm9sbG93LWF1dG8gKGZvbGxvdy1tb2RlIDEpKSkKLS0gCjIuNi4yCgo= --001a11c310be622b2405238f7547 Content-Type: text/x-patch; charset=US-ASCII; name="0002-lisp-isearch.el-Bind-a-variable-while-lazy-highlight.patch" Content-Disposition: attachment; filename="0002-lisp-isearch.el-Bind-a-variable-while-lazy-highlight.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_igi180x61 RnJvbSA4YTUyZjEyODcyZDJiOTlhY2IyY2E1YTIwNzdjY2Q4Nzc3OTMwOWZlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBcnR1ciBNYWxhYmFyYmEgPGJydWNlLmNvbm5vci5hbUBnbWFp bC5jb20+CkRhdGU6IE1vbiwgMiBOb3YgMjAxNSAxMzo1NDoxNSArMDAwMApTdWJqZWN0OiBbUEFU Q0ggMi8zXSAqIGxpc3AvaXNlYXJjaC5lbDogQmluZCBhIHZhcmlhYmxlIHdoaWxlCiBsYXp5LWhp Z2hsaWdodGluZwoKKGlzZWFyY2gtbGF6eS1oaWdobGlnaHQtb25nb2luZy1zZWFyY2gpOiBOZXcg dmFyaWFibGUuCihpc2VhcmNoLWxhenktaGlnaGxpZ2h0LXNlYXJjaCk6IFVzZSBpdC4KLS0tCiBs aXNwL2lzZWFyY2guZWwgfCA3ICsrKysrKysKIDEgZmlsZSBjaGFuZ2VkLCA3IGluc2VydGlvbnMo KykKCmRpZmYgLS1naXQgYS9saXNwL2lzZWFyY2guZWwgYi9saXNwL2lzZWFyY2guZWwKaW5kZXgg NjQ0MjE2Ni4uZWY0OTY1MCAxMDA2NDQKLS0tIGEvbGlzcC9pc2VhcmNoLmVsCisrKyBiL2xpc3Av aXNlYXJjaC5lbApAQCAtMzA4MCwxMSArMzA4MCwxOCBAQCBpc2VhcmNoLWxhenktaGlnaGxpZ2h0 LW5ldy1sb29wCiAJICAgICAgKHJ1bi13aXRoLWlkbGUtdGltZXIgbGF6eS1oaWdobGlnaHQtaW5p dGlhbC1kZWxheSBuaWwKIAkJCQkgICAnaXNlYXJjaC1sYXp5LWhpZ2hsaWdodC11cGRhdGUpKSkp KQogCisoZGVmdmFyIGlzZWFyY2gtbGF6eS1oaWdobGlnaHQtb25nb2luZy1zZWFyY2ggbmlsCisg ICJEeW5hbWljYWxseSBib3VuZCB0byB0IGluIGBpc2VhcmNoLWxhenktaGlnaGxpZ2h0LXNlYXJj aCcuCitUaGlzIGNhbiBiZSB1c2VkIGJ5IGBpc2VhcmNoLXNlYXJjaC1mdW4tZnVuY3Rpb24nIHRv IGRldGVjdAord2hldGhlciBpdHMgcmV0dXJuIHZhbHVlIGlzIGJlaW5nIHJ1biBmb3IgYSBwcm9w ZXIgdXNlciBzZWFyY2ggb3IKK2EgbGF6eSBoaWdobGlnaHQgc2VhcmNoLiIpCisKIChkZWZ1biBp c2VhcmNoLWxhenktaGlnaGxpZ2h0LXNlYXJjaCAoKQogICAiU2VhcmNoIGFoZWFkIGZvciB0aGUg bmV4dCBvciBwcmV2aW91cyBtYXRjaCwgZm9yIGxhenkgaGlnaGxpZ2h0aW5nLgogQXR0ZW1wdCB0 byBkbyB0aGUgc2VhcmNoIGV4YWN0bHkgdGhlIHdheSB0aGUgcGVuZGluZyBJc2VhcmNoIHdvdWxk LiIKICAgKGNvbmRpdGlvbi1jYXNlIG5pbAogICAgICAgKGxldCAoKGNhc2UtZm9sZC1zZWFyY2gg aXNlYXJjaC1sYXp5LWhpZ2hsaWdodC1jYXNlLWZvbGQtc2VhcmNoKQorICAgICAgICAgICAgKGlz ZWFyY2gtbGF6eS1oaWdobGlnaHQtb25nb2luZy1zZWFyY2ggdCkKIAkgICAgKGlzZWFyY2gtcmVn ZXhwIGlzZWFyY2gtbGF6eS1oaWdobGlnaHQtcmVnZXhwKQogCSAgICAoaXNlYXJjaC1yZWdleHAt ZnVuY3Rpb24gaXNlYXJjaC1sYXp5LWhpZ2hsaWdodC1yZWdleHAtZnVuY3Rpb24pCiAJICAgIChp c2VhcmNoLWxheC13aGl0ZXNwYWNlCi0tIAoyLjYuMgoK --001a11c310be622b2405238f7547 Content-Type: text/x-patch; charset=US-ASCII; name="0001-lisp-isearch.el-Allow-lazy-highlighting-of-all-windo.patch" Content-Disposition: attachment; filename="0001-lisp-isearch.el-Allow-lazy-highlighting-of-all-windo.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_igi180xd2 RnJvbSAwYzgxNWZhMjEwMDFiNGEyOWYxMjRlOGVkYTU4Zjc4ODk1NjBkNzAxIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBcnR1ciBNYWxhYmFyYmEgPGJydWNlLmNvbm5vci5hbUBnbWFp bC5jb20+CkRhdGU6IE1vbiwgMiBOb3YgMjAxNSAxMjowOToxNiArMDAwMApTdWJqZWN0OiBbUEFU Q0ggMS8zXSAqIGxpc3AvaXNlYXJjaC5lbDogQWxsb3cgbGF6eS1oaWdobGlnaHRpbmcgb2YgYWxs IHdpbmRvd3MKCihpc2VhcmNoLWxhenktaGlnaGxpZ2h0KTogTmV3IHBvc3NpYmxlIHZhbHVlLgoo aXNlYXJjaC1sYXp5LWhpZ2hsaWdodC11cGRhdGUpOiBVc2UgaXQuCi0tLQogbGlzcC9pc2VhcmNo LmVsIHwgMTIgKysrKysrKysrLS0tCiAxIGZpbGUgY2hhbmdlZCwgOSBpbnNlcnRpb25zKCspLCAz IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2xpc3AvaXNlYXJjaC5lbCBiL2xpc3AvaXNlYXJj aC5lbAppbmRleCBiNzYyODg0Li42NDQyMTY2IDEwMDY0NAotLS0gYS9saXNwL2lzZWFyY2guZWwK KysrIGIvbGlzcC9pc2VhcmNoLmVsCkBAIC0yNzksOCArMjc5LDEzIEBAIGlzZWFyY2gtbGF6eS1o aWdobGlnaHQKICAgIkNvbnRyb2xzIHRoZSBsYXp5LWhpZ2hsaWdodGluZyBkdXJpbmcgaW5jcmVt ZW50YWwgc2VhcmNoLgogV2hlbiBub24tbmlsLCBhbGwgdGV4dCBpbiB0aGUgYnVmZmVyIG1hdGNo aW5nIHRoZSBjdXJyZW50IHNlYXJjaAogc3RyaW5nIGlzIGhpZ2hsaWdodGVkIGxhemlseSAoc2Vl IGBsYXp5LWhpZ2hsaWdodC1pbml0aWFsLWRlbGF5JwotYW5kIGBsYXp5LWhpZ2hsaWdodC1pbnRl cnZhbCcpLiIKLSAgOnR5cGUgJ2Jvb2xlYW4KK2FuZCBgbGF6eS1oaWdobGlnaHQtaW50ZXJ2YWwn KS4KKworV2hlbiBtdWx0aXBsZSB3aW5kb3dzIGRpc3BsYXkgdGhlIGN1cnJlbnQgYnVmZmVyLCB0 aGUKK2hpZ2hsaWdodGluZyBpcyBkaXNwbGF5ZWQgb25seSBvbiB0aGUgc2VsZWN0ZWQgd2luZG93 LCB1bmxlc3MKK3RoaXMgdmFyaWFibGUgaXMgc2V0IHRvIHRoZSBzeW1ib2wgYGFsbC13aW5kb3dz Jy4iCisgIDp0eXBlICcoY2hvaWNlIGJvb2xlYW4KKyAgICAgICAgICAgICAgICAgKGNvbnN0IDp0 YWcgIk9uLCBhbmQgYXBwbGllZCB0byBhbGwgd2luZG93cyIgYWxsLXdpbmRvd3MpKQogICA6Z3Jv dXAgJ2xhenktaGlnaGxpZ2h0CiAgIDpncm91cCAnaXNlYXJjaCkKIApAQCAtMzE2Miw3ICszMTY3 LDggQEAgaXNlYXJjaC1sYXp5LWhpZ2hsaWdodC11cGRhdGUKIAkJCSAgOzsgYnV0IGxvd2VyIHRo YW4gaXNlYXJjaCBtYWluIG92ZXJsYXkncyAxMDAxCiAJCQkgIChvdmVybGF5LXB1dCBvdiAncHJp b3JpdHkgMTAwMCkKIAkJCSAgKG92ZXJsYXktcHV0IG92ICdmYWNlIGxhenktaGlnaGxpZ2h0LWZh Y2UpCi0JCQkgIChvdmVybGF5LXB1dCBvdiAnd2luZG93IChzZWxlY3RlZC13aW5kb3cpKSkpCisg ICAgICAgICAgICAgICAgICAgICAgICAgICh1bmxlc3MgKGVxIGlzZWFyY2gtbGF6eS1oaWdobGln aHQgJ2FsbC13aW5kb3dzKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIChvdmVybGF5LXB1 dCBvdiAnd2luZG93IChzZWxlY3RlZC13aW5kb3cpKSkpKQogCQkgICAgICA7OyBSZW1lbWJlciB0 aGUgY3VycmVudCBwb3NpdGlvbiBvZiBwb2ludCBmb3IKIAkJICAgICAgOzsgdGhlIG5leHQgY2Fs bCBvZiBgaXNlYXJjaC1sYXp5LWhpZ2hsaWdodC11cGRhdGUnCiAJCSAgICAgIDs7IHdoZW4gYGxh enktaGlnaGxpZ2h0LW1heC1hdC1hLXRpbWUnIGlzIHRvbyBzbWFsbC4KLS0gCjIuNi4yCgo= --001a11c310be622b2405238f7547-- From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 10:43:21 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 15:43:21 +0000 Received: from localhost ([127.0.0.1]:49861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtHGR-0006qc-Tk for submit@debbugs.gnu.org; Mon, 02 Nov 2015 10:43:20 -0500 Received: from mail.muc.de ([193.149.48.3]:21962) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtHG6-0006pp-Jd for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 10:43:18 -0500 Received: (qmail 6817 invoked by uid 3782); 2 Nov 2015 15:42:57 -0000 Received: from acm.muc.de (p5B147B71.dip0.t-ipconnect.de [91.20.123.113]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 02 Nov 2015 16:42:56 +0100 Received: (qmail 14043 invoked by uid 1000); 2 Nov 2015 15:44:45 -0000 Date: Mon, 2 Nov 2015 15:44:45 +0000 To: Artur Malabarba Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151102154445.GD11804@acm.fritz.box> References: <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: Juri Linkov , 17453@debbugs.gnu.org, emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello again, Artur On Mon, Nov 02, 2015 at 02:18:59PM +0000, Artur Malabarba wrote: > > > Lazy highlighting searches for matches on the current window. It must > > > be extended to search for matches on the Follow Mode group of windows. > > > For that, it needs the details of the "window*-start" and "window*-end". > > Yes, you're right, I see that now. This might still be solvable via > > setting isearch-search-fun-function, I'll need to think on that for a > > moment. > Here's a new version, split into 3 short patches to make it easier to > understand. Thanks. I understand what you're suggesting, now, and I think it's a good idea, on the whole. However, about the bug where, with lazy highlighting active, isearch scrolls the window its on rather than moving to the next one: as I said, this is caused by the "(sit-for 0)" near the beginning of isearch-lazy-highlight-new-loop. The purpose of this is to scroll the display, in case point has moved off of the window. The bug cause is now clear: ..-lazy-highlight-new-loop first scrolls the window, then checks whether it needs to restart its lazy h. loop. If it does, it starts the timer which triggers ..-lazy-highlight-update after the delay. The bug is that all this checking happens in ...-lazy-h-new-loop rather than in ...-lazy-h-update. If we moved all the checking to ..l-h-update, then there would be no need for "(sit-for 0)" - the command loop redisplay would already have scrolled the windows, if necessary; and Follow Mode would already have shifted point to the right window. So how about us just moving all these checks to where they really belong, in isearch-lazy-highlight-update? I've a feeling that if we do this, then your function follow--search-function becomes unneeded. Juri? ######################################################################### A related point in one of your patches below. It explicitly selects one of the Follow Mode windows. This is bad. Follow Mode itself choses the right window in its post-command-hook. Second-guessing it within the command processing is liable to lead to confusion, maintenance difficulties, and general pain. Another point. It is better to use follow-all-followers to get at the windows rather than get-buffer-window-list. The first of these is guaranteed to get the windows in the right order, and also allows for a future enhancement whereby only some of the windows displaying are part of the Follow Mode group. Of course, anything using follow-all-followers needs to be textually in follow.el. > This makes 2 small changes to isearch (which I think are even > justifiable on their own, regardless of follow-mode), and defines a > new function in follow-mode which takes care of two things: > Matches are highlighted on all windows Here, the matches should be highlighted on all the windows in the FM group without exception. I think a new option you're providing allows lazy highlighting to happen only in the current window. This is a bad idea when FM is active. > When the user types something, and the next match is on another > window, switch to that window instead of scrolling the current one. > From caf5adfc0b7caf07dc74813242f9ecc664babc13 Mon Sep 17 00:00:00 2001 > From: Artur Malabarba > Date: Mon, 2 Nov 2015 14:01:18 +0000 > Subject: [PATCH 3/3] * lisp/follow.el: Improve isearch compatibility > > (follow--search-function): New function. > (follow-mode): Configure `isearch-lazy-highlight' and > `isearch-search-fun-function'. > --- > lisp/follow.el | 33 +++++++++++++++++++++++++++++++++ > 1 file changed, 33 insertions(+) > > diff --git a/lisp/follow.el b/lisp/follow.el > index 938c59e..0b80f04 100644 > --- a/lisp/follow.el > +++ b/lisp/follow.el > @@ -419,6 +419,9 @@ follow-mode > :keymap follow-mode-map > (if follow-mode > (progn > + (setq-local isearch-search-fun-function #'follow--search-function) > + (when isearch-lazy-highlight > + (setq-local isearch-lazy-highlight 'all-windows)) > (add-hook 'compilation-filter-hook 'follow-align-compilation-windows t t) > (add-hook 'post-command-hook 'follow-post-command-hook t) > (add-hook 'window-size-change-functions 'follow-window-size-change t)) > @@ -434,6 +437,36 @@ follow-mode > (remove-hook 'window-size-change-functions 'follow-window-size-change))) > (remove-hook 'compilation-filter-hook 'follow-align-compilation-windows t))) > > +(defun follow--search-function () > + "Return a function suitable for `isearch-search-fun-function'." > + (lambda (string &optional bound noerror count) > + (let* ((search-function (isearch-search-fun-default)) > + (all-followers (follow-all-followers)) > + ;; If bound at the edge of the window, extend it to the > + ;; edges know by `follow-mode'. > + (bound (cond ((equal bound (window-end)) > + (window-end (car (last all-followers)))) > + ((equal bound (window-start)) > + (window-start (car all-followers))) > + (t bound))) > + (matched (funcall search-function string bound noerror count))) > + ;; If this is a proper user-triggered search (and not just a > + ;; lazy-highlight search), and if the search matched, and if the > + ;; match is not visible on this window... > + (when (and matched > + (not isearch-lazy-highlight-ongoing-search) > + (not (and (pos-visible-in-window-p (match-beginning 0)) > + (pos-visible-in-window-p (match-end 0))))) > + ;; ... see if the match is visible on another window. > + (let ((win (seq-find (lambda (w) > + (and (pos-visible-in-window-p (match-beginning 0) w) > + (pos-visible-in-window-p (match-end 0) w))) > + all-followers))) > + ;; If so, select it. > + (when win > + (select-window win)))) <=========================== > + matched))) > + > (defun follow-find-file-hook () > "Find-file hook for Follow mode. See the variable `follow-auto'." > (if follow-auto (follow-mode 1))) > -- > 2.6.2 > > From 8a52f12872d2b99acb2ca5a2077ccd87779309fe Mon Sep 17 00:00:00 2001 > From: Artur Malabarba > Date: Mon, 2 Nov 2015 13:54:15 +0000 > Subject: [PATCH 2/3] * lisp/isearch.el: Bind a variable while > lazy-highlighting > > (isearch-lazy-highlight-ongoing-search): New variable. > (isearch-lazy-highlight-search): Use it. > --- > lisp/isearch.el | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/lisp/isearch.el b/lisp/isearch.el > index 6442166..ef49650 100644 > --- a/lisp/isearch.el > +++ b/lisp/isearch.el > @@ -3080,11 +3080,18 @@ isearch-lazy-highlight-new-loop > (run-with-idle-timer lazy-highlight-initial-delay nil > 'isearch-lazy-highlight-update))))) > > +(defvar isearch-lazy-highlight-ongoing-search nil > + "Dynamically bound to t in `isearch-lazy-highlight-search'. > +This can be used by `isearch-search-fun-function' to detect > +whether its return value is being run for a proper user search or > +a lazy highlight search.") > + > (defun isearch-lazy-highlight-search () > "Search ahead for the next or previous match, for lazy highlighting. > Attempt to do the search exactly the way the pending Isearch would." > (condition-case nil > (let ((case-fold-search isearch-lazy-highlight-case-fold-search) > + (isearch-lazy-highlight-ongoing-search t) > (isearch-regexp isearch-lazy-highlight-regexp) > (isearch-regexp-function isearch-lazy-highlight-regexp-function) > (isearch-lax-whitespace > -- > 2.6.2 > > From 0c815fa21001b4a29f124e8eda58f7889560d701 Mon Sep 17 00:00:00 2001 > From: Artur Malabarba > Date: Mon, 2 Nov 2015 12:09:16 +0000 > Subject: [PATCH 1/3] * lisp/isearch.el: Allow lazy-highlighting of all windows > > (isearch-lazy-highlight): New possible value. > (isearch-lazy-highlight-update): Use it. > --- > lisp/isearch.el | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/lisp/isearch.el b/lisp/isearch.el > index b762884..6442166 100644 > --- a/lisp/isearch.el > +++ b/lisp/isearch.el > @@ -279,8 +279,13 @@ isearch-lazy-highlight > "Controls the lazy-highlighting during incremental search. > When non-nil, all text in the buffer matching the current search > string is highlighted lazily (see `lazy-highlight-initial-delay' > -and `lazy-highlight-interval')." > - :type 'boolean > +and `lazy-highlight-interval'). > + > +When multiple windows display the current buffer, the > +highlighting is displayed only on the selected window, unless > +this variable is set to the symbol `all-windows'." > + :type '(choice boolean > + (const :tag "On, and applied to all windows" all-windows)) > :group 'lazy-highlight > :group 'isearch) > > @@ -3162,7 +3167,8 @@ isearch-lazy-highlight-update > ;; but lower than isearch main overlay's 1001 > (overlay-put ov 'priority 1000) > (overlay-put ov 'face lazy-highlight-face) > - (overlay-put ov 'window (selected-window)))) > + (unless (eq isearch-lazy-highlight 'all-windows) > + (overlay-put ov 'window (selected-window))))) > ;; Remember the current position of point for > ;; the next call of `isearch-lazy-highlight-update' > ;; when `lazy-highlight-max-at-a-time' is too small. > -- > 2.6.2 > -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 10:46:27 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 15:46:27 +0000 Received: from localhost ([127.0.0.1]:49865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtHJT-0006w2-CL for submit@debbugs.gnu.org; Mon, 02 Nov 2015 10:46:27 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:52728) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtHJQ-0006vp-MI for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 10:46:26 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NX700G002DW4500@a-mtaout21.012.net.il> for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 17:46:22 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NX700GJ92HA1060@a-mtaout21.012.net.il>; Mon, 02 Nov 2015 17:46:22 +0200 (IST) Date: Mon, 02 Nov 2015 17:46:34 +0200 From: Eli Zaretskii Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. In-reply-to: <20151102123512.GB11804@acm.fritz.box> X-012-Sender: halo1@inter.net.il To: Alan Mackenzie Message-id: <831tc8xv39.fsf@gnu.org> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, monnier@iro.umontreal.ca, bruce.connor.am@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Lets' take emacs-devel out of this shall we? > Date: Mon, 2 Nov 2015 12:35:12 +0000 > From: Alan Mackenzie > Cc: Juri Linkov , 17453@debbugs.gnu.org, > Stefan Monnier , > emacs-devel > > > Maybe I missed part of the issue. I thought you wanted Isearch to > > switch to another window if that window contains the next match > > (instead of scrolling the current window). For that, you only need > > pos-visible-in-window-p, you don't need to mess with boundaries. > > What is causing the unwanted scrolling rather than moving to the next > window, is the form "(sit-for 0)" near the start of > isearch-lazy-highlight-new-loop. When point is outside the window, this > form causes redisplay, which scrolls point back into the window - > without Follow Mode getting a look in. In my patch, I replaced this > with "(sit*-for 0)", where Follow Mode can do its thing before the > redisplay happens. If this means that sit*-for does something other than redisplay and wait, like switch to another window, I'd really suggest to rethink that. It is entirely counter-intuitive to have a sit-for family of functions do anything other than some kind of redisplay and some kind of waiting. I think it is a better idea to have Isearch switch to another window when the next hit is there, via some specialized movement command that Follow mode could customize. That'd be something expectable. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 11:05:57 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 16:05:58 +0000 Received: from localhost ([127.0.0.1]:49871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtHcL-0007Pi-Fp for submit@debbugs.gnu.org; Mon, 02 Nov 2015 11:05:57 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:37307) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtHc1-0007PA-9F for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 11:05:55 -0500 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tA2G5Y1T005047 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Nov 2015 16:05:36 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tA2G5Yfr007232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2015 16:05:34 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tA2G5X2I022616; Mon, 2 Nov 2015 16:05:33 GMT MIME-Version: 1.0 Message-ID: <0720f8ad-2a93-4e10-910c-998736af06a8@default> Date: Mon, 2 Nov 2015 08:05:32 -0800 (PST) From: Drew Adams To: Eli Zaretskii , Alan Mackenzie Subject: RE: bug#17453: Isearch doesn't work properly with Follow Mode. References: <<20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box>> <<87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box>> <<87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box>> <<831tc8xv39.fsf@gnu.org>> In-Reply-To: <<831tc8xv39.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0021.oracle.com [156.151.31.71] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, monnier@iro.umontreal.ca, bruce.connor.am@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > Lets' take emacs-devel out of this shall we? Enfin ! From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 11:07:31 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 16:07:31 +0000 Received: from localhost ([127.0.0.1]:49875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtHdr-0007SU-2U for submit@debbugs.gnu.org; Mon, 02 Nov 2015 11:07:31 -0500 Received: from mail.muc.de ([193.149.48.3]:31476) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtHdp-0007SJ-5y for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 11:07:29 -0500 Received: (qmail 12296 invoked by uid 3782); 2 Nov 2015 16:07:28 -0000 Received: from acm.muc.de (p5B147B71.dip0.t-ipconnect.de [91.20.123.113]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 02 Nov 2015 17:07:27 +0100 Received: (qmail 14130 invoked by uid 1000); 2 Nov 2015 16:09:17 -0000 Date: Mon, 2 Nov 2015 16:09:17 +0000 To: Eli Zaretskii Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151102160917.GE11804@acm.fritz.box> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <831tc8xv39.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831tc8xv39.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, monnier@iro.umontreal.ca, bruce.connor.am@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Eli. On Mon, Nov 02, 2015 at 05:46:34PM +0200, Eli Zaretskii wrote: > Lets' take emacs-devel out of this shall we? OK. > > Date: Mon, 2 Nov 2015 12:35:12 +0000 > > From: Alan Mackenzie > > Cc: Juri Linkov , 17453@debbugs.gnu.org, > > Stefan Monnier , > > emacs-devel > > > Maybe I missed part of the issue. I thought you wanted Isearch to > > > switch to another window if that window contains the next match > > > (instead of scrolling the current window). For that, you only need > > > pos-visible-in-window-p, you don't need to mess with boundaries. > > What is causing the unwanted scrolling rather than moving to the next > > window, is the form "(sit-for 0)" near the start of > > isearch-lazy-highlight-new-loop. When point is outside the window, this > > form causes redisplay, which scrolls point back into the window - > > without Follow Mode getting a look in. In my patch, I replaced this > > with "(sit*-for 0)", where Follow Mode can do its thing before the > > redisplay happens. > If this means that sit*-for does something other than redisplay and > wait, like switch to another window, I'd really suggest to rethink > that. It is entirely counter-intuitive to have a sit-for family of > functions do anything other than some kind of redisplay and some kind > of waiting. sit*-for's synchronising windows, switching to the appropriate window, etc., is conceptually an extension of redisplay's scrolling to get point on screen. But I think sit*-for could well be not needed here, anyway. > I think it is a better idea to have Isearch switch to another window > when the next hit is there, via some specialized movement command that > Follow mode could customize. That'd be something expectable. No. The right fix is not to do "(sit-for 0)" at that point in the processing. As I explained at length to Artur in another post today, if we move lazy-highlight's checking whether window-start/end have changed, into the function triggered by the timer, redisplay will already have happened and so we won't need that offending sit-for. Then Follow Mode will quite naturally select the next window (via its post-command-hook), rather than isearch forcibly scrolling the first one. As currently happens when lazy highlighting is disabled. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 11:26:27 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 16:26:27 +0000 Received: from localhost ([127.0.0.1]:49898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtHwA-0007xA-Nx for submit@debbugs.gnu.org; Mon, 02 Nov 2015 11:26:27 -0500 Received: from mail-lb0-f174.google.com ([209.85.217.174]:36168) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtHw8-0007wz-La for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 11:26:25 -0500 Received: by lbjm5 with SMTP id m5so91776465lbj.3 for <17453@debbugs.gnu.org>; Mon, 02 Nov 2015 08:26:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=W7ae/B+SJtOKhJClD4RyMu3rv9UMOdAkNsDEOJnAjZU=; b=NB90gVLvUd8vxPp4WIzx87ghSWkOy7EwLt3xMVSixVRPCMFzxFPFknlTT6fhndWxYT mjJus2wWi66pCm237FztPN0U8wbmIDbwaQhUIe3Zq90KVCS6+Zy9jNAsBdaA7LWLPW/0 sOUl+ToogcDdfJ+Sf5pnR5XXtLwBZEOVnaVMAQfdScZB9Bc+JtLlOTAE+qCYm+h2iOqZ d/V3buTsOVa67PCDGfgoPfoIJaSjTuD2gDkXzlp/zhMx5ESEuHl0Z00dsEdqID01Rxdq 7wjgodgZo3d/yn8tEvQTkxJp7LQ7q5C5d4wuXM5az6w5VixnoJC3Y8tygBHyk5E+jBPg 6lsQ== MIME-Version: 1.0 X-Received: by 10.112.35.196 with SMTP id k4mr10478436lbj.3.1446481583683; Mon, 02 Nov 2015 08:26:23 -0800 (PST) Received: by 10.112.63.71 with HTTP; Mon, 2 Nov 2015 08:26:23 -0800 (PST) In-Reply-To: <20151102154445.GD11804@acm.fritz.box> References: <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> Date: Mon, 2 Nov 2015 16:26:23 +0000 X-Google-Sender-Auth: fWgv0Dc0xqFj-4TVNTzo_NCRg4Q Message-ID: Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. From: Artur Malabarba To: Alan Mackenzie Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bruce.connor.am@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hi Alan, 2015-11-02 15:44 GMT+00:00 Alan Mackenzie : > So how about us just moving all these checks to where they really > belong, in isearch-lazy-highlight-update? I've a feeling that if we do > this, then your function follow--search-function becomes unneeded. Yes, I think this might work too. And I like the idea of eliminating a redisplay inside the command-loop. Could you test it? You'll probably still need a simpler version of that follow--search-function to ensure that lazy-highlighting extends to all windows (instead of stopping inside the selected-window), but at least it won't need that `select-window' part that you said is bad. :-) >> Matches are highlighted on all windows > > Here, the matches should be highlighted on all the windows in the FM > group without exception. I think a new option you're providing allows > lazy highlighting to happen only in the current window. This is a bad > idea when FM is active. No, currently lazy highlighting to happens only in the current window (with or without follow-mode). This happens for 2 reasons. (1) Isearch only highlights between window-start and window-end, and (2) isearch limits the highlithing overlays to only be displayed on the selected window. The new option I introduced to isearch allows the highlighting overlays to be displayed on all windows (solving (2)). Furthermore, one of features of that follow--search-function function is to make sure that highlighting doesn't stop `window-end' (solving (1)). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 11:35:29 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 16:35:29 +0000 Received: from localhost ([127.0.0.1]:49903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtI4v-0001Jz-9Z for submit@debbugs.gnu.org; Mon, 02 Nov 2015 11:35:29 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:27421) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtI4t-0001Jq-Dl for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 11:35:27 -0500 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tA2GZQUM007159 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Nov 2015 16:35:26 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tA2GZPRt007238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2015 16:35:25 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tA2GZPN1026830; Mon, 2 Nov 2015 16:35:25 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 2 Nov 2015 08:35:24 -0800 (PST) From: Drew Adams To: bruce.connor.am@gmail.com, Alan Mackenzie Subject: RE: bug#17453: Isearch doesn't work properly with Follow Mode. References: <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > one of features of that follow--search-function function is to make > sure that highlighting doesn't stop `window-end' (solving (1)). I believe this was already taken care of by work that Juri did recently. I don't have time to look this up now, but see recent bug reports. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 12:45:53 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 17:45:53 +0000 Received: from localhost ([127.0.0.1]:49925 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtJB3-00034b-34 for submit@debbugs.gnu.org; Mon, 02 Nov 2015 12:45:53 -0500 Received: from mtaout29.012.net.il ([80.179.55.185]:42951) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtJAg-000346-MK for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 12:45:51 -0500 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NX7003007XR5O00@mtaout29.012.net.il> for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 19:44:49 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NX7002I77YPQG00@mtaout29.012.net.il>; Mon, 02 Nov 2015 19:44:49 +0200 (IST) Date: Mon, 02 Nov 2015 19:45:41 +0200 From: Eli Zaretskii Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. In-reply-to: <20151102154445.GD11804@acm.fritz.box> X-012-Sender: halo1@inter.net.il To: Alan Mackenzie Message-id: <83y4egwb0a.fsf@gnu.org> References: <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, bruce.connor.am@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 2 Nov 2015 15:44:45 +0000 > From: Alan Mackenzie > Cc: Juri Linkov , 17453@debbugs.gnu.org, > emacs-devel > > A related point in one of your patches below. It explicitly selects one > of the Follow Mode windows. This is bad. Follow Mode itself choses the > right window in its post-command-hook. Second-guessing it within the > command processing is liable to lead to confusion, maintenance > difficulties, and general pain. You could call the same code that post-command-hook calls, then it wouldn't be second-guessing. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 12:49:36 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 17:49:36 +0000 Received: from localhost ([127.0.0.1]:49931 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtJEd-0003AH-Ra for submit@debbugs.gnu.org; Mon, 02 Nov 2015 12:49:36 -0500 Received: from mtaout27.012.net.il ([80.179.55.183]:52190) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtJEb-0003A7-CZ for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 12:49:34 -0500 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NX700B007XD9200@mtaout27.012.net.il> for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 19:44:54 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NX7008G37YUOI20@mtaout27.012.net.il>; Mon, 02 Nov 2015 19:44:54 +0200 (IST) Date: Mon, 02 Nov 2015 19:49:43 +0200 From: Eli Zaretskii Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. In-reply-to: <20151102160917.GE11804@acm.fritz.box> X-012-Sender: halo1@inter.net.il To: Alan Mackenzie Message-id: <83wpu0watk.fsf@gnu.org> References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <831tc8xv39.fsf@gnu.org> <20151102160917.GE11804@acm.fritz.box> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, monnier@iro.umontreal.ca, bruce.connor.am@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 2 Nov 2015 16:09:17 +0000 > Cc: bruce.connor.am@gmail.com, juri@linkov.net, 17453@debbugs.gnu.org, > monnier@iro.umontreal.ca > From: Alan Mackenzie > > > If this means that sit*-for does something other than redisplay and > > wait, like switch to another window, I'd really suggest to rethink > > that. It is entirely counter-intuitive to have a sit-for family of > > functions do anything other than some kind of redisplay and some kind > > of waiting. > > sit*-for's synchronising windows, switching to the appropriate window, > etc., is conceptually an extension of redisplay's scrolling to get point > on screen. No, redisplay doesn't necessarily scroll. It does so only if needed. So sit-for should not be thought as a way to scroll the window, even if sometimes it does. > But I think sit*-for could well be not needed here, anyway. That's okay, but my point is: please do not add to established functions code that does on behalf of Follow mode something that conceptually doesn't belong to those functions. OK? From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 14:18:40 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 19:18:40 +0000 Received: from localhost ([127.0.0.1]:49968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtKcq-0005RX-8H for submit@debbugs.gnu.org; Mon, 02 Nov 2015 14:18:40 -0500 Received: from mail-lb0-f172.google.com ([209.85.217.172]:34946) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtKco-0005RN-F7 for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 14:18:39 -0500 Received: by lbbes7 with SMTP id es7so94910541lbb.2 for <17453@debbugs.gnu.org>; Mon, 02 Nov 2015 11:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=I6x4vAY54GMTImLnaY9/t/7fXfzBNtnbTu0wJkR6flE=; b=07xzYCY/57BMkGOaVhvU3t89Ty7RxVgIDKiZ4RpC/SVZ1z5gJ2G0DpwlbhSeVT/qyp fVHX9fg5YaoufrTOSa3sOP3Xvkkmyx6nDuvghR1e096kusO8vKjXCGU7u9QG6Zpx7Bv7 iZiaMD6aal5y7ktlDGqcyp88IWb1U3RBg51+pQ3BR7c7plg3gHAG7ppy8sBOPnFN6MJW Of4UGVrMSp/epksQ8Mj3w4q/dVxZlfx5E9Ic9bzVbuLWoP7gWJT5dbuSFuh37Kdzx17L JPNs9nJJeN2vyCZ/5TtzUQELrsXQ/XOkTetUCiywHXW1SY+FpVOaE0cE0c+GZ62xbWoU i7KA== MIME-Version: 1.0 X-Received: by 10.112.135.233 with SMTP id pv9mr11054853lbb.42.1446491917660; Mon, 02 Nov 2015 11:18:37 -0800 (PST) Received: by 10.112.63.71 with HTTP; Mon, 2 Nov 2015 11:18:37 -0800 (PST) In-Reply-To: References: <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> Date: Mon, 2 Nov 2015 19:18:37 +0000 X-Google-Sender-Auth: F0I2hHsT2KG8XU2dyrgfW6XvtWM Message-ID: Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. From: Artur Malabarba To: Drew Adams Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: Alan Mackenzie , 17453@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bruce.connor.am@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 2015-11-02 16:35 GMT+00:00 Drew Adams : >> one of features of that follow--search-function function is to make >> sure that highlighting doesn't stop `window-end' (solving (1)). > > I believe this was already taken care of by work that Juri did recently. > I don't have time to look this up now, but see recent bug reports. I ran a git log on isearch.el and I think you're referring to this change: 10ec0468dfbc0815a772cc46a031aca298af0985 Lazy-highlight the whole string at point (debbugs:19353) If so, that's just about extending the bound a little bit to ensure it holds a whole symbol. follow-mode actually needs to extend the bound a lot more (up 'till the `window-end' of the last window in the group). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 14:28:23 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 19:28:23 +0000 Received: from localhost ([127.0.0.1]:49975 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtKmF-0005iK-Cn for submit@debbugs.gnu.org; Mon, 02 Nov 2015 14:28:23 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:31148) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtKmD-0005iC-CV for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 14:28:21 -0500 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tA2JSKG8027540 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Nov 2015 19:28:20 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tA2JSKnp031611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2015 19:28:20 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tA2JSJDl001875; Mon, 2 Nov 2015 19:28:19 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 2 Nov 2015 11:28:18 -0800 (PST) From: Drew Adams To: bruce.connor.am@gmail.com Subject: RE: bug#17453: Isearch doesn't work properly with Follow Mode. References: <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 17453 Cc: Alan Mackenzie , 17453@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > I believe this was already taken care of by work that Juri did recently= . > > I don't have time to look this up now, but see recent bug reports. >=20 > I ran a git log on isearch.el and I think you're referring to this change= : >=20 > 10ec0468dfbc0815a772cc46a031aca298af0985 Lazy-highlight the whole > string at point (debbugs:19353) >=20 > If so, that's just about extending the bound a little bit to ensure it > holds a whole symbol. follow-mode actually needs to extend the bound a > lot more (up 'till the `window-end' of the last window in the group). Please check with Juri. I'm pretty sure the discussion included the possibility of having lazy highlighting throughout a buffer. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 15:38:24 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 20:38:25 +0000 Received: from localhost ([127.0.0.1]:49993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtLs0-0000ic-MI for submit@debbugs.gnu.org; Mon, 02 Nov 2015 15:38:24 -0500 Received: from mail-qg0-f41.google.com ([209.85.192.41]:34125) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtLre-0000i0-Uv for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 15:38:21 -0500 Received: by qgem9 with SMTP id m9so126132842qge.1 for <17453@debbugs.gnu.org>; Mon, 02 Nov 2015 12:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mime-version:content-type; bh=LriFiMvafjJUztUAJHfbdpaztMQR0vn21SvF74fV3S0=; b=WIu9Lb+oePq6MkVWVSY99xhCDK9lE4zjksJZKEX6pQrdDHpXOXE/SEl4A1fUSyrNu5 gZneFi3/tDGSf+Aa1wld0Uh1YJ980KonFSknMCq1OVvWEl9CFsQm0EOVRvWFno23/q1N 0SHURmm15/p+7JxuHC5GVHpTVAf62D9Lkqwf/hsAQXov+BiVY4+CEbdWS2VendkA0cmx klMPFcz+WFbQ4dkLBmXnciRZNCSTbRFpYF2rmOyTInUnLylA9tbkMHK231h1GVSv4LaU KnGXLLODEo4ppW1jhh+k6NNl4qavGWmLeuqFo8mFq+zYnf3YKq3oeN8uvd1yt9XG6IfH J7Aw== X-Received: by 10.140.18.146 with SMTP id 18mr32392261qgf.1.1446496682470; Mon, 02 Nov 2015 12:38:02 -0800 (PST) Received: from Hermes-2.local ([192.54.222.4]) by smtp.gmail.com with ESMTPSA id w201sm6668025qka.5.2015.11.02.12.38.01 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 02 Nov 2015 12:38:01 -0800 (PST) Received: by Hermes-2.local (Postfix, from userid 501) id AA811485DFB3; Mon, 2 Nov 2015 15:38:06 -0500 (EST) From: "John Wiegley" To: Eli Zaretskii Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. In-Reply-To: <83wpu0watk.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 02 Nov 2015 19:49:43 +0200") Date: Mon, 02 Nov 2015 15:35:51 -0500 Message-ID: References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <831tc8xv39.fsf@gnu.org> <20151102160917.GE11804@acm.fritz.box> <83wpu0watk.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: Alan Mackenzie , 17453@debbugs.gnu.org, monnier@iro.umontreal.ca, bruce.connor.am@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >>>>> Eli Zaretskii writes: > That's okay, but my point is: please do not add to established functions > code that does on behalf of Follow mode something that conceptually doesn't > belong to those functions. OK? I'd like to second this request. John From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 17:08:01 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 22:08:01 +0000 Received: from localhost ([127.0.0.1]:50066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtNGi-0002yZ-9l for submit@debbugs.gnu.org; Mon, 02 Nov 2015 17:08:00 -0500 Received: from mail.muc.de ([193.149.48.3]:50860) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtNGN-0002y8-Mi for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 17:07:59 -0500 Received: (qmail 93978 invoked by uid 3782); 2 Nov 2015 22:07:38 -0000 Received: from acm.muc.de (p5B147B71.dip0.t-ipconnect.de [91.20.123.113]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 02 Nov 2015 23:07:37 +0100 Received: (qmail 12338 invoked by uid 1000); 2 Nov 2015 22:09:27 -0000 Date: Mon, 2 Nov 2015 22:09:27 +0000 To: Artur Malabarba Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151102220927.GA2118@acm.fritz.box> References: <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: Eli Zaretskii , 17453@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello again, Artur. On Mon, Nov 02, 2015 at 04:26:23PM +0000, Artur Malabarba wrote: > Hi Alan, > 2015-11-02 15:44 GMT+00:00 Alan Mackenzie : > > So how about us just moving all these checks to where they really > > belong, in isearch-lazy-highlight-update? I've a feeling that if we do > > this, then your function follow--search-function becomes unneeded. > Yes, I think this might work too. And I like the idea of eliminating a > redisplay inside the command-loop. > Could you test it? Of course, nothing is ever that simple. ;-). I've got a working version which doesn't use "(sit-for 0)", thus allowing point to move properly over Follow Mode windows. However, this meant the "old" highlighting not being erased until the 0.25 seconds had passed. So I tried testing the conditions for a new lazy-highlight loop (apart from window-start/end changing) in the command loop bit. This doesn't work brilliantly well when a C-s causes a half-screen forward scroll: the "upper" lazy highlighting remains there, and 0.25s later the "lower" lazy H. appears. It struck me that instead of all this rigmarole, and instead of the "(sit-for 0)", we could test whether or not a scroll is about to take place. The obvious candidate for this is `pos-visible-in-window-p' - if this returns nil, obviously a scroll is about to happen. Unfortunately, even if p-v-i-w-p returns t, a scroll might still happen because of `scroll-margin', and the like. What we could do with is an interface which will tell us whether or not redisplay would scroll if invoked immediately, with the current value of point, window-start, etc. Obviously it would be simple, but messy to hack a lisp function together to do this, but a more general purpose function might be apposite here. Eli, what do you think? All this is, just for the moment, disregarding any enhancements needed to support Follow Mode properly. Just for the moment, that is. If you're interested, here is a (still scrappy) patch of where I am at the moment. diff --git a/lisp/isearch.el b/lisp/isearch.el index b762884..b59a224 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -3012,13 +3012,52 @@ 'isearch-lazy-highlight-cleanup "22.1") (defun isearch-lazy-highlight-new-loop (&optional beg end) - "Cleanup any previous `lazy-highlight' loop and begin a new one. -BEG and END specify the bounds within which highlighting should occur. -This is called when `isearch-update' is invoked (which can cause the -search string to change or the window to scroll). It is also used -by other Emacs features." + "Set an idle timer, which will trigger a new `lazy-highlight' loop. +BEG and END specify the bounds within which highlighting should +occur. This is called when `isearch-update' is invoked (which +can cause the search string to change or the window(s) to +scroll). It is also used by other Emacs features." + (setq isearch-lazy-highlight-start-limit beg + isearch-lazy-highlight-end-limit end) + (when (null executing-kbd-macro) + (when (or (not (equal isearch-string + isearch-lazy-highlight-last-string)) + (not (eq (selected-window) + isearch-lazy-highlight-window)) + (not (eq isearch-lazy-highlight-case-fold-search + isearch-case-fold-search)) + (not (eq isearch-lazy-highlight-regexp + isearch-regexp)) + (not (eq isearch-lazy-highlight-regexp-function + isearch-regexp-function)) + (not (eq isearch-lazy-highlight-lax-whitespace + isearch-lax-whitespace)) + (not (eq isearch-lazy-highlight-regexp-lax-whitespace + isearch-regexp-lax-whitespace)) + ;; (not (= (window-start) + ;; isearch-lazy-highlight-window-start)) + ;; (not (= (window-end) ; Window may have been split/joined. + ;; isearch-lazy-highlight-window-end)) + (not (eq isearch-forward + isearch-lazy-highlight-forward)) + ;; In case we are recovering from an error. + (not (equal isearch-error + isearch-lazy-highlight-error))) + (lazy-highlight-cleanup t)) ;kill old loop & remove overlays. + (setq isearch-lazy-highlight-timer + (run-with-idle-timer lazy-highlight-initial-delay nil + 'isearch-lazy-highlight-maybe-new-loop)))) + +(defun isearch-lazy-highlight-maybe-new-loop () + "If needed, cleanup the previous `lazy-highlight' loop and begin a new one. +Return t if we begin a loop, nil otherwise." +;; " Cleanup any previous `lazy-highlight' loop and begin a new one. +;; BEG and END specify the bounds within which highlighting should occur. +;; This is called when `isearch-update' is invoked (which can cause the +;; search string to change or the window to scroll). It is also used +;; by other Emacs features." (when (and (null executing-kbd-macro) - (sit-for 0) ;make sure (window-start) is credible + ;; (sit-for 0) ;make sure (window-start) is credible (or (not (equal isearch-string isearch-lazy-highlight-last-string)) (not (eq (selected-window) @@ -3048,8 +3087,8 @@ isearch-lazy-highlight-new-loop ;; It used to check for `(not isearch-error)' here, but actually ;; lazy-highlighting might find matches to highlight even when ;; `isearch-error' is non-nil. (Bug#9918) - (setq isearch-lazy-highlight-start-limit beg - isearch-lazy-highlight-end-limit end) + ;; (setq isearch-lazy-highlight-start-limit beg + ;; isearch-lazy-highlight-end-limit end) (setq isearch-lazy-highlight-window (selected-window) isearch-lazy-highlight-window-start (window-start) isearch-lazy-highlight-window-end (window-end) @@ -3070,10 +3109,12 @@ isearch-lazy-highlight-new-loop isearch-lazy-highlight-regexp-lax-whitespace isearch-regexp-lax-whitespace isearch-lazy-highlight-regexp-function isearch-regexp-function isearch-lazy-highlight-forward isearch-forward) - (unless (equal isearch-string "") - (setq isearch-lazy-highlight-timer - (run-with-idle-timer lazy-highlight-initial-delay nil - 'isearch-lazy-highlight-update))))) + ;; (unless (equal isearch-string "") + ;; (setq isearch-lazy-highlight-timer + ;; (run-with-idle-timer lazy-highlight-initial-delay nil + ;; 'isearch-lazy-highlight-update))) + (unless (equal isearch-string "") + (isearch-lazy-highlight-update)))) (defun isearch-lazy-highlight-search () "Search ahead for the next or previous match, for lazy highlighting. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 18:00:26 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 23:00:26 +0000 Received: from localhost ([127.0.0.1]:50116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtO5R-0006DB-PM for submit@debbugs.gnu.org; Mon, 02 Nov 2015 18:00:26 -0500 Received: from mail-lf0-f47.google.com ([209.85.215.47]:33064) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtO5P-0006A5-CF for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 18:00:24 -0500 Received: by lfbf136 with SMTP id f136so56080256lfb.0 for <17453@debbugs.gnu.org>; Mon, 02 Nov 2015 15:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cYFG0a/3UubkkjQ8cAXzKHh3w2cT6ZeIvLk7Vd2OxEc=; b=pnCPoQdnTgWU+lh4iU5vIpXzl2ECM5s0/F6GzlwQ0ADeBW1d9L6icblEfvObctEQ+2 b+4hbrN1COjswF7CHVqmBiXN8BUn7jGdanps2XX4dO4M1IoIEOghv/gt/cnJyleANaWt gXMR0jOSdcdi/UB8tlBNSNEI/QBv94Prq/G4ZCxN3curFSv6in9gmoR7t/wnt0vzjx0L ZyMOi6HCuAC17Z5Nk7xyPj+8Sr/IWoV/VoaFuJ43QW8NHj+lzeWRrchXbTKVt7++wnk7 nracoMpNAYfUXcbQveXy0PUUh7xvYOE1k8OqbJ16ZA2h70scTVZB5AwTDSvXlV9j8fvp htyw== MIME-Version: 1.0 X-Received: by 10.112.62.232 with SMTP id b8mr11051713lbs.27.1446505222468; Mon, 02 Nov 2015 15:00:22 -0800 (PST) Received: by 10.112.63.71 with HTTP; Mon, 2 Nov 2015 15:00:21 -0800 (PST) Received: by 10.112.63.71 with HTTP; Mon, 2 Nov 2015 15:00:21 -0800 (PST) In-Reply-To: <20151102220927.GA2118@acm.fritz.box> References: <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> <20151102220927.GA2118@acm.fritz.box> Date: Mon, 2 Nov 2015 23:00:21 +0000 X-Google-Sender-Auth: cf0dlhAfMY4zig5x0iq-RPQvU7E Message-ID: Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. From: Artur Malabarba To: Alan Mackenzie Content-Type: multipart/alternative; boundary=001a11c3c402f37892052396bd50 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: Eli Zaretskii , 17453@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bruce.connor.am@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c3c402f37892052396bd50 Content-Type: text/plain; charset=UTF-8 On 2 Nov 2015 10:09 pm, "Alan Mackenzie" wrote: > Of course, nothing is ever that simple. ;-). I've got a working > version which doesn't use "(sit-for 0)", thus allowing point to move > properly over Follow Mode windows. > > However, this meant the "old" highlighting not being erased until the > 0.25 seconds had passed. So I tried testing the conditions for a new > lazy-highlight loop (apart from window-start/end changing) in the > command loop bit. > It struck me that instead of all this rigmarole, and instead of the > "(sit-for 0)", we could test whether or not a scroll is about to take > place. Or we can cleanup the lazy highlighting _when_ scrolling takes place. > What we could do with is an interface which will tell us whether or not > redisplay would scroll if invoked immediately, with the current value of > point, window-start, etc. I don't think that's necessary. What if isearch just added (lazy-highlight-cleanup t) to window-scroll-functions? I want to be very cautious about not increasing the complexity of isearch code here, but so far these sound like good refactorings to me. --001a11c3c402f37892052396bd50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 2 Nov 2015 10:09 pm, "Alan Mackenzie" <acm@muc.de> wrote:
> Of course, nothing is ever that simple.=C2=A0 ;-).=C2=A0 I've got = a working
> version which doesn't use "(sit-for 0)", thus allowing p= oint to move
> properly over Follow Mode windows.
>
> However, this meant the "old" highlighting not being erased = until the
> 0.25 seconds had passed.=C2=A0 So I tried testing the conditions for a= new
> lazy-highlight loop (apart from window-start/end changing) in the
> command loop bit.=C2=A0
> It struck me that instead of all this rigmarole, and instead of the > "(sit-for 0)", we could test whether or not a scroll is abou= t to take
> place.

Or we can cleanup the lazy highlighting _when_ scrolling tak= es place.

> What we could do with is an interface which will tell u= s whether or not
> redisplay would scroll if invoked immediately, with the current value = of
> point, window-start, etc.=C2=A0

I don't think that's necessary. What if isearch just= added =C2=A0(lazy-highlight-cleanup t) to window-scroll-functions?

I want to be very cautious about not increasing the complexi= ty of isearch code here, but so far these sound like good refactorings to m= e.

--001a11c3c402f37892052396bd50-- From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 18:23:03 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 23:23:03 +0000 Received: from localhost ([127.0.0.1]:50129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtORL-00087O-2f for submit@debbugs.gnu.org; Mon, 02 Nov 2015 18:23:03 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:51286 helo=homiemail-a23.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtORI-00086u-BC for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 18:23:01 -0500 Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id C0CBF4B006D; Mon, 2 Nov 2015 15:22:58 -0800 (PST) Received: from localhost.linkov.net (62.65.227.66.cable.starman.ee [62.65.227.66]) (Authenticated sender: jurta@jurta.org) by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 957C44B0063; Mon, 2 Nov 2015 15:22:57 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Organization: LINKOV.NET References: <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> Date: Tue, 03 Nov 2015 01:22:03 +0200 In-Reply-To: <20151102154445.GD11804@acm.fritz.box> (Alan Mackenzie's message of "Mon, 2 Nov 2015 15:44:45 +0000") Message-ID: <87h9l46l7o.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Artur Malabarba , emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > So how about us just moving all these checks to where they really > belong, in isearch-lazy-highlight-update? I've a feeling that if we do > this, then your function follow--search-function becomes unneeded. > > Juri? Right, without (sit-for 0) it's possible to switch focus to adjacent windows with just adding 2 lines to follow.el, i.e. I get the desired behavior with: diff --git a/lisp/follow.el b/lisp/follow.el index 938c59e..0433854 100644 --- a/lisp/follow.el +++ b/lisp/follow.el @@ -420,6 +420,7 @@ (define-minor-mode follow-mode (if follow-mode (progn (add-hook 'compilation-filter-hook 'follow-align-compilation-windows t t) + (add-hook 'isearch-update-post-hook 'follow-align-compilation-windows t t) (add-hook 'post-command-hook 'follow-post-command-hook t) (add-hook 'window-size-change-functions 'follow-window-size-change t)) ;; Remove globally-installed hook functions only if there is no @@ -432,6 +433,7 @@ (define-minor-mode follow-mode (unless following (remove-hook 'post-command-hook 'follow-post-command-hook) (remove-hook 'window-size-change-functions 'follow-window-size-change))) + (remove-hook 'isearch-update-post-hook 'follow-align-compilation-windows t) (remove-hook 'compilation-filter-hook 'follow-align-compilation-windows t))) (defun follow-find-file-hook () diff --git a/lisp/isearch.el b/lisp/isearch.el index b762884..8edf8b0 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -3018,7 +3018,7 @@ (defun isearch-lazy-highlight-new-loop (&optional beg end) search string to change or the window to scroll). It is also used by other Emacs features." (when (and (null executing-kbd-macro) - (sit-for 0) ;make sure (window-start) is credible + ; (sit-for 0) ;make sure (window-start) is credible (or (not (equal isearch-string isearch-lazy-highlight-last-string)) (not (eq (selected-window) So what remains to do is to fix this bug, but I don't understand the logic you proposed: how checks could be moved to isearch-lazy-highlight-update if isearch-lazy-highlight-update is scheduled by a timer conditionally depending on these checks? From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 18:29:32 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 23:29:32 +0000 Received: from localhost ([127.0.0.1]:50137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtOXb-0008MN-PL for submit@debbugs.gnu.org; Mon, 02 Nov 2015 18:29:32 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:49106 helo=homiemail-a12.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtOXI-0008Lg-33 for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 18:29:30 -0500 Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 9B04D103006C; Mon, 2 Nov 2015 15:29:10 -0800 (PST) Received: from localhost.linkov.net (62.65.227.66.cable.starman.ee [62.65.227.66]) (Authenticated sender: jurta@jurta.org) by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 2CFF51030063; Mon, 2 Nov 2015 15:29:08 -0800 (PST) From: Juri Linkov To: Artur Malabarba Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Organization: LINKOV.NET References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> Date: Tue, 03 Nov 2015 01:28:40 +0200 In-Reply-To: (Artur Malabarba's message of "Mon, 2 Nov 2015 14:18:59 +0000") Message-ID: <87d1vs56c7.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: Alan Mackenzie , 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > +(defvar isearch-lazy-highlight-ongoing-search nil > + "Dynamically bound to t in `isearch-lazy-highlight-search'. > +This can be used by `isearch-search-fun-function' to detect > +whether its return value is being run for a proper user search or > +a lazy highlight search.") > + > (defun isearch-lazy-highlight-search () > "Search ahead for the next or previous match, for lazy highlighting. > Attempt to do the search exactly the way the pending Isearch would." > (condition-case nil > (let ((case-fold-search isearch-lazy-highlight-case-fold-search) > + (isearch-lazy-highlight-ongoing-search t) > (isearch-regexp isearch-lazy-highlight-regexp) > (isearch-regexp-function isearch-lazy-highlight-regexp-function) > (isearch-lax-whitespace Please note that this is unnecessary because all functions that override isearch-search-fun-function use its =E2=80=98bounds=E2=80=99 arg to detec= t whether it's called from isearch-search or isearch-lazy-highlight-search with the valu= e either nil or non-nil correspondingly. > @@ -279,8 +279,13 @@ isearch-lazy-highlight > "Controls the lazy-highlighting during incremental search. > When non-nil, all text in the buffer matching the current search > string is highlighted lazily (see `lazy-highlight-initial-delay' > -and `lazy-highlight-interval')." > - :type 'boolean > +and `lazy-highlight-interval'). > + > +When multiple windows display the current buffer, the > +highlighting is displayed only on the selected window, unless > +this variable is set to the symbol `all-windows'." > + :type '(choice boolean > + (const :tag "On, and applied to all windows" all-wind= ows)) > :group 'lazy-highlight > :group 'isearch) > =20 > @@ -3162,7 +3167,8 @@ isearch-lazy-highlight-update > ;; but lower than isearch main overlay's 1001 > (overlay-put ov 'priority 1000) > (overlay-put ov 'face lazy-highlight-face) > - (overlay-put ov 'window (selected-window)))) > + (unless (eq isearch-lazy-highlight 'all-wind= ows) > + (overlay-put ov 'window (selected-window))= ))) This is a good option that follow-mode could set (or users to customize). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 18:33:38 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 23:33:38 +0000 Received: from localhost ([127.0.0.1]:50149 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtOba-0008VQ-EY for submit@debbugs.gnu.org; Mon, 02 Nov 2015 18:33:38 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:35914 helo=homiemail-a76.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtObY-0008VG-9z for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 18:33:36 -0500 Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 737D445807C; Mon, 2 Nov 2015 15:33:35 -0800 (PST) Received: from localhost.linkov.net (62.65.227.66.cable.starman.ee [62.65.227.66]) (Authenticated sender: jurta@jurta.org) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 4644F45807B; Mon, 2 Nov 2015 15:33:34 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Organization: LINKOV.NET References: <20140509224458.GA4205@acm.acm> <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> Date: Tue, 03 Nov 2015 01:33:06 +0200 In-Reply-To: <20151102092853.GA11804@acm.fritz.box> (Alan Mackenzie's message of "Mon, 2 Nov 2015 09:28:53 +0000") Message-ID: <87io5k3rkd.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Stefan Monnier , emacs-devel@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> IIUC, lazy highlighting is not a problem anymore, .... > > It is. With Follow Mode enabled, lazy highlighting is only occurring i= n > the one window, not all of them. Perhaps you missed my patch in the previous message that will highlight matches in all windows after Artur will add a new option =E2=80=98all-windows=E2=80=99 to =E2=80=98isearch-lazy-highl= ight=E2=80=99 to lift the selected-window-only restriction from lazy overlays. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 18:47:40 2015 Received: (at 17453) by debbugs.gnu.org; 2 Nov 2015 23:47:40 +0000 Received: from localhost ([127.0.0.1]:50155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtOp9-0000O3-Qq for submit@debbugs.gnu.org; Mon, 02 Nov 2015 18:47:40 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:58853 helo=homiemail-a101.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtOp8-0000Nw-5e for 17453@debbugs.gnu.org; Mon, 02 Nov 2015 18:47:38 -0500 Received: from homiemail-a101.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTP id 4E14A117E078; Mon, 2 Nov 2015 15:47:37 -0800 (PST) Received: from localhost.linkov.net (62.65.227.66.cable.starman.ee [62.65.227.66]) (Authenticated sender: jurta@jurta.org) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTPA id 1C27D117E06A; Mon, 2 Nov 2015 15:47:35 -0800 (PST) From: Juri Linkov To: Drew Adams Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Organization: LINKOV.NET References: <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> Date: Tue, 03 Nov 2015 01:45:54 +0200 In-Reply-To: (Drew Adams's message of "Mon, 2 Nov 2015 11:28:18 -0800 (PST)") Message-ID: <87d1vs3qxd.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: Alan Mackenzie , 17453@debbugs.gnu.org, bruce.connor.am@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> > I believe this was already taken care of by work that Juri did recently. >> > I don't have time to look this up now, but see recent bug reports. >> >> I ran a git log on isearch.el and I think you're referring to this change: >> >> 10ec0468dfbc0815a772cc46a031aca298af0985 Lazy-highlight the whole >> string at point (debbugs:19353) >> >> If so, that's just about extending the bound a little bit to ensure it >> holds a whole symbol. follow-mode actually needs to extend the bound a >> lot more (up 'till the `window-end' of the last window in the group). > > Please check with Juri. I'm pretty sure the discussion included > the possibility of having lazy highlighting throughout a buffer. Yes, what I meant is: diff --git a/lisp/follow.el b/lisp/follow.el index 938c59e..fc970bb 100644 --- a/lisp/follow.el +++ b/lisp/follow.el @@ -419,6 +419,7 @@ (define-minor-mode follow-mode :keymap follow-mode-map (if follow-mode (progn + (setq-local lazy-highlight-buffer t) (add-hook 'compilation-filter-hook 'follow-align-compilation-windows t t) (add-hook 'post-command-hook 'follow-post-command-hook t) (add-hook 'window-size-change-functions 'follow-window-size-change t)) From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 03:33:21 2015 Received: (at 17453) by debbugs.gnu.org; 3 Nov 2015 08:33:21 +0000 Received: from localhost ([127.0.0.1]:50399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtX1s-0004j3-A8 for submit@debbugs.gnu.org; Tue, 03 Nov 2015 03:33:20 -0500 Received: from mail.muc.de ([193.149.48.3]:44028) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtX1o-0004iq-DY for 17453@debbugs.gnu.org; Tue, 03 Nov 2015 03:33:17 -0500 Received: (qmail 65412 invoked by uid 3782); 3 Nov 2015 08:33:14 -0000 Received: from acm.muc.de (p5B14700A.dip0.t-ipconnect.de [91.20.112.10]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 03 Nov 2015 09:33:13 +0100 Received: (qmail 2282 invoked by uid 1000); 3 Nov 2015 08:35:02 -0000 Date: Tue, 3 Nov 2015 08:35:02 +0000 To: Eli Zaretskii Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151103083502.GA2258@acm.fritz.box> References: <20151029232302.GB3812@acm.fritz.box> <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <831tc8xv39.fsf@gnu.org> <20151102160917.GE11804@acm.fritz.box> <83wpu0watk.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83wpu0watk.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, bruce.connor.am@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On Mon, Nov 02, 2015 at 07:49:43PM +0200, Eli Zaretskii wrote: > > Date: Mon, 2 Nov 2015 16:09:17 +0000 > > Cc: bruce.connor.am@gmail.com, juri@linkov.net, 17453@debbugs.gnu.org, > > monnier@iro.umontreal.ca > > From: Alan Mackenzie > > > If this means that sit*-for does something other than redisplay and > > > wait, like switch to another window, I'd really suggest to rethink > > > that. It is entirely counter-intuitive to have a sit-for family of > > > functions do anything other than some kind of redisplay and some kind > > > of waiting. > > sit*-for's synchronising windows, switching to the appropriate window, > > etc., is conceptually an extension of redisplay's scrolling to get point > > on screen. > No, redisplay doesn't necessarily scroll. It does so only if needed. > So sit-for should not be thought as a way to scroll the window, even > if sometimes it does. Redisplay scrolls sometimes, and it moves point sometimes. But it does those things only when needed for the actual display. Similarly the sit*-for, invoking display would do other things strictly necessary for successful redisplay. That sometimes would include resynchronising the windows, for example. > > But I think sit*-for could well be not needed here, anyway. > That's okay, but my point is: please do not add to established > functions code that does on behalf of Follow mode something that > conceptually doesn't belong to those functions. OK? Fine! -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 04:17:21 2015 Received: (at 17453) by debbugs.gnu.org; 3 Nov 2015 09:17:22 +0000 Received: from localhost ([127.0.0.1]:50413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtXiT-0006Bg-Fk for submit@debbugs.gnu.org; Tue, 03 Nov 2015 04:17:21 -0500 Received: from mail.muc.de ([193.149.48.3]:56769) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtXi7-0006Ag-UW for 17453@debbugs.gnu.org; Tue, 03 Nov 2015 04:17:19 -0500 Received: (qmail 75038 invoked by uid 3782); 3 Nov 2015 09:16:59 -0000 Received: from acm.muc.de (p5B14700A.dip0.t-ipconnect.de [91.20.112.10]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 03 Nov 2015 10:16:58 +0100 Received: (qmail 2636 invoked by uid 1000); 3 Nov 2015 09:18:47 -0000 Date: Tue, 3 Nov 2015 09:18:47 +0000 To: Artur Malabarba Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151103091847.GC2258@acm.fritz.box> References: <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> <20151102220927.GA2118@acm.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: Eli Zaretskii , 17453@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Artur. On Mon, Nov 02, 2015 at 11:00:21PM +0000, Artur Malabarba wrote: > On 2 Nov 2015 10:09 pm, "Alan Mackenzie" wrote: > > Of course, nothing is ever that simple. ;-). I've got a working > > version which doesn't use "(sit-for 0)", thus allowing point to move > > properly over Follow Mode windows. > > However, this meant the "old" highlighting not being erased until the > > 0.25 seconds had passed. So I tried testing the conditions for a new > > lazy-highlight loop (apart from window-start/end changing) in the > > command loop bit. > > It struck me that instead of all this rigmarole, and instead of the > > "(sit-for 0)", we could test whether or not a scroll is about to take > > place. > Or we can cleanup the lazy highlighting _when_ scrolling takes place. > > What we could do with is an interface which will tell us whether or not > > redisplay would scroll if invoked immediately, with the current value of > > point, window-start, etc. > I don't think that's necessary. What if isearch just added > (lazy-highlight-cleanup t) to window-scroll-functions? Now that's a good idea. :-) So stale lazy highlighting could be erased by the multitude of existing tests for most cases, and by that hook function for when we scroll. I'm going to try it. > I want to be very cautious about not increasing the complexity of isearch > code here, but so far these sound like good refactorings to me. I agree on both counts. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 07:29:34 2015 Received: (at 17453) by debbugs.gnu.org; 3 Nov 2015 12:29:34 +0000 Received: from localhost ([127.0.0.1]:50525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtaiT-0003dM-Dj for submit@debbugs.gnu.org; Tue, 03 Nov 2015 07:29:33 -0500 Received: from mail.muc.de ([193.149.48.3]:18308) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtaiQ-0003dC-Kl for 17453@debbugs.gnu.org; Tue, 03 Nov 2015 07:29:31 -0500 Received: (qmail 24359 invoked by uid 3782); 3 Nov 2015 12:29:28 -0000 Received: from acm.muc.de (p5B14700A.dip0.t-ipconnect.de [91.20.112.10]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 03 Nov 2015 13:29:27 +0100 Received: (qmail 3447 invoked by uid 1000); 3 Nov 2015 12:31:16 -0000 Date: Tue, 3 Nov 2015 12:31:16 +0000 To: Juri Linkov Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151103123116.GD2258@acm.fritz.box> References: <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h9l46l7o.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, Artur Malabarba , emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Juri. On Tue, Nov 03, 2015 at 01:22:03AM +0200, Juri Linkov wrote: > > So how about us just moving all these checks to where they really > > belong, in isearch-lazy-highlight-update? I've a feeling that if we do > > this, then your function follow--search-function becomes unneeded. > > > > Juri? > Right, without (sit-for 0) it's possible to switch focus to adjacent windows > with just adding 2 lines to follow.el, i.e. I get the desired behavior with: > diff --git a/lisp/follow.el b/lisp/follow.el > index 938c59e..0433854 100644 > --- a/lisp/follow.el > +++ b/lisp/follow.el > @@ -420,6 +420,7 @@ (define-minor-mode follow-mode > (if follow-mode > (progn > (add-hook 'compilation-filter-hook 'follow-align-compilation-windows t t) > + (add-hook 'isearch-update-post-hook 'follow-align-compilation-windows t t) > (add-hook 'post-command-hook 'follow-post-command-hook t) > (add-hook 'window-size-change-functions 'follow-window-size-change t)) > ;; Remove globally-installed hook functions only if there is no > @@ -432,6 +433,7 @@ (define-minor-mode follow-mode > (unless following > (remove-hook 'post-command-hook 'follow-post-command-hook) > (remove-hook 'window-size-change-functions 'follow-window-size-change))) > + (remove-hook 'isearch-update-post-hook 'follow-align-compilation-windows t) > (remove-hook 'compilation-filter-hook 'follow-align-compilation-windows t))) > (defun follow-find-file-hook () This is complicated. Ideally, the Follow Mode windows should be synchronised in FM's post-command-hook, not isearch's. It is not isearch's job to realign windows. follow-post-command-hook both realigns windows and choses an appropriate window to put point in. We should let it. > diff --git a/lisp/isearch.el b/lisp/isearch.el > index b762884..8edf8b0 100644 > --- a/lisp/isearch.el > +++ b/lisp/isearch.el > @@ -3018,7 +3018,7 @@ (defun isearch-lazy-highlight-new-loop (&optional beg end) > search string to change or the window to scroll). It is also used > by other Emacs features." > (when (and (null executing-kbd-macro) > - (sit-for 0) ;make sure (window-start) is credible > + ; (sit-for 0) ;make sure (window-start) is credible > (or (not (equal isearch-string > isearch-lazy-highlight-last-string)) > (not (eq (selected-window) > So what remains to do is to fix this bug, but I don't understand the logic > you proposed: how checks could be moved to isearch-lazy-highlight-update > if isearch-lazy-highlight-update is scheduled by a timer conditionally > depending on these checks? What I'm proposing is to schedule the timer always, and do the checks (for whether we need to start a new lazy highlight loop) in the function that the timer triggers. The advantage is that when the timer triggers, redisplay will already have taken place[*], and thus we can use `window-start' and `window-end' without forcing an artificial redisplay with "(sit-for 0)". [*] and an appropriate FM window will have been selected by FM's post-command-hook The disadvantage is that stale lazy highlights are erased after isearch-lazy-highlight-initial-delay, not immediately, as at present. I'm not sure if this is really a disadvantage or not. In my scrappy patch last night, I attempted to ameliorate this "problem" by repeating (most of) the tests in the command-loop bit. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 10:49:45 2015 Received: (at 17453) by debbugs.gnu.org; 3 Nov 2015 15:49:46 +0000 Received: from localhost ([127.0.0.1]:51630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtdqD-0002RY-FI for submit@debbugs.gnu.org; Tue, 03 Nov 2015 10:49:45 -0500 Received: from mtaout29.012.net.il ([80.179.55.185]:59575) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtdqB-0002RP-IR for 17453@debbugs.gnu.org; Tue, 03 Nov 2015 10:49:44 -0500 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NX800O00WXLLY00@mtaout29.012.net.il> for 17453@debbugs.gnu.org; Tue, 03 Nov 2015 17:48:22 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NX800KA3X8MCM60@mtaout29.012.net.il>; Tue, 03 Nov 2015 17:48:22 +0200 (IST) Date: Tue, 03 Nov 2015 17:49:17 +0200 From: Eli Zaretskii Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. In-reply-to: <20151103123116.GD2258@acm.fritz.box> X-012-Sender: halo1@inter.net.il To: Alan Mackenzie Message-id: <83a8qvw0aq.fsf@gnu.org> References: <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> <20151103123116.GD2258@acm.fritz.box> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, bruce.connor.am@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) PLEASE let's keep emacs-devel out of this?? > Date: Tue, 3 Nov 2015 12:31:16 +0000 > From: Alan Mackenzie > Cc: 17453@debbugs.gnu.org, Artur Malabarba , > emacs-devel > > This is complicated. Ideally, the Follow Mode windows should be > synchronised in FM's post-command-hook, not isearch's. It is not > isearch's job to realign windows. follow-post-command-hook both realigns > windows and choses an appropriate window to put point in. We should let > it. Once again, if some code in Isearch calls the same function that is used in follow-post-command-hook, the above is not an issue. Moreover, saving some calls to the hook will make Emacs more responsive. (Right now, using Follow mode is a pain due to the hook: even a simple C-f is annoyingly slow.) > What I'm proposing is to schedule the timer always, and do the checks > (for whether we need to start a new lazy highlight loop) in the function > that the timer triggers. The advantage is that when the timer triggers, > redisplay will already have taken place[*] I don't think you can count on that: if there's a ripe timer, it will be processed before redisplay. I think. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 11:18:48 2015 Received: (at 17453) by debbugs.gnu.org; 3 Nov 2015 16:18:48 +0000 Received: from localhost ([127.0.0.1]:51651 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZteIJ-0003Bc-Lw for submit@debbugs.gnu.org; Tue, 03 Nov 2015 11:18:47 -0500 Received: from mail-lf0-f43.google.com ([209.85.215.43]:35096) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZteII-0003BU-0f for 17453@debbugs.gnu.org; Tue, 03 Nov 2015 11:18:46 -0500 Received: by lfbn126 with SMTP id n126so23872667lfb.2 for <17453@debbugs.gnu.org>; Tue, 03 Nov 2015 08:18:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=X74ji3eULI+iTNkUi6x7w5Ay19diL8CUOXccsrwPkfQ=; b=J5ET9hPFNe2Ktxzrikm/EQBDzOIwC0MBLCx4jzjz3G1mNTLOKyz93hxZl3qrA7JUAM Pp7iEpdDwYOSDjA9oddqR1jxvtQH2Oa9aUIFIo40Noh6YZSB1uQDyMFCahojMBFcqqqt wfGLHMsRGhHc/9HBTeufdQGC+b74nnS9rmZdnLespD8gfz8RIx184+lYeEhuv0DD+djp +wAHtLhkuVdIF3SXtvvDOweVkwJbUAC0BFk9jfgsUzln5Kn5rpwEcO6snsCI3MMucO5M EwfU1VwKfJzmrwgsIcMdZ0XKlvLYfjnuDoNgnLgiCgoOzRho6KWMhZf672EQwg5LBTd0 mABg== MIME-Version: 1.0 X-Received: by 10.112.157.105 with SMTP id wl9mr7366446lbb.2.1446567525217; Tue, 03 Nov 2015 08:18:45 -0800 (PST) Received: by 10.112.63.71 with HTTP; Tue, 3 Nov 2015 08:18:45 -0800 (PST) In-Reply-To: <83a8qvw0aq.fsf@gnu.org> References: <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> <20151103123116.GD2258@acm.fritz.box> <83a8qvw0aq.fsf@gnu.org> Date: Tue, 3 Nov 2015 16:18:45 +0000 X-Google-Sender-Auth: IvGSbv-wLaeC4E30FoM2l8-GwKA Message-ID: Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. From: Artur Malabarba To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: Alan Mackenzie , 17453@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bruce.connor.am@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 2015-11-03 15:49 GMT+00:00 Eli Zaretskii : >> This is complicated. Ideally, the Follow Mode windows should be >> synchronised in FM's post-command-hook, not isearch's. It is not >> isearch's job to realign windows. follow-post-command-hook both realigns >> windows and choses an appropriate window to put point in. We should let >> it. > > Once again, if some code in Isearch calls the same function that is > used in follow-post-command-hook, the above is not an issue. > Moreover, saving some calls to the hook will make Emacs more > responsive. I agree with Eli and Juri on this. If there's a solution as simple as calling a follow-mode function in isearch-post-update-hook, then this sounds like a no-downside solution. Of course it's not isearch's job to realign windows, but that's why the hook exists: so that other packages can run their own functions and do their own jobs at that point in time. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 11:38:11 2015 Received: (at 17453) by debbugs.gnu.org; 3 Nov 2015 16:38:11 +0000 Received: from localhost ([127.0.0.1]:51665 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zteb5-0003jR-1L for submit@debbugs.gnu.org; Tue, 03 Nov 2015 11:38:11 -0500 Received: from mail.muc.de ([193.149.48.3]:49457) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zteb1-0003jF-L8 for 17453@debbugs.gnu.org; Tue, 03 Nov 2015 11:38:08 -0500 Received: (qmail 86283 invoked by uid 3782); 3 Nov 2015 16:38:06 -0000 Received: from acm.muc.de (p5B14700A.dip0.t-ipconnect.de [91.20.112.10]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 03 Nov 2015 17:38:05 +0100 Received: (qmail 13461 invoked by uid 1000); 3 Nov 2015 16:39:55 -0000 Date: Tue, 3 Nov 2015 16:39:55 +0000 To: Eli Zaretskii Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151103163955.GF2258@acm.fritz.box> References: <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> <20151103123116.GD2258@acm.fritz.box> <83a8qvw0aq.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83a8qvw0aq.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, bruce.connor.am@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Eli. On Tue, Nov 03, 2015 at 05:49:17PM +0200, Eli Zaretskii wrote: > PLEASE let's keep emacs-devel out of this?? OK. > > Date: Tue, 3 Nov 2015 12:31:16 +0000 > > From: Alan Mackenzie > > Cc: 17453@debbugs.gnu.org, Artur Malabarba , > > emacs-devel > > This is complicated. Ideally, the Follow Mode windows should be > > synchronised in FM's post-command-hook, not isearch's. It is not > > isearch's job to realign windows. follow-post-command-hook both realigns > > windows and choses an appropriate window to put point in. We should let > > it. > Once again, if some code in Isearch calls the same function that is > used in follow-post-command-hook, the above is not an issue. > Moreover, saving some calls to the hook will make Emacs more > responsive. (Right now, using Follow mode is a pain due to the hook: > even a simple C-f is annoyingly slow.) The follow-post-command-hook will run anyway. If Isearch directly invokes that Follow Mode function, f-p-c-h will be run a second time. That's one of the reasons I want to avoid it. > > What I'm proposing is to schedule the timer always, and do the checks > > (for whether we need to start a new lazy highlight loop) in the function > > that the timer triggers. The advantage is that when the timer triggers, > > redisplay will already have taken place[*] > I don't think you can count on that: if there's a ripe timer, it will > be processed before redisplay. I think. Ah. So if somebody sets isearch-lazy-highlighting-intial-delay to 0.00001 seconds, it will trigger before redisplay has happened. Yes. Here's another idea. In place of that "(sit-for 0)", I add another condition (redisplay-would-scroll-window-p) , with the following in (probably) window.el: (defun redisplay-would-scroll-window-p (&optional pos window) "Would redisplay scroll WINDOW vertically on an immediate redisplay? WINDOW defaults to the current window. POS, the position of point which is to be tested defaults to the value of point in WINDOW. The buffer displayed by WINDOW is assumed to be the current buffer. Return t if a vertical scroll would be triggered by redisplay, otherwise nil." (or window (setq window (selected-window))) (or pos (setq pos (window-point window))) (with-selected-window window (with-current-buffer (window-buffer) (not (and (pos-visible-in-window-p pos) (or (<= scroll-margin 0) (let* ((this-scroll-margin (min scroll-margin (/ (window-body-height) 4))) (top-limit (save-excursion (move-to-window-line this-scroll-margin) (point))) (bottom-limit (save-excursion (move-to-window-line (- this-scroll-margin)) (point)))) (and (>= pos top-limit) (< pos bottom-limit))))))))) . -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 17:10:07 2015 Received: (at 17453) by debbugs.gnu.org; 3 Nov 2015 22:10:07 +0000 Received: from localhost ([127.0.0.1]:51938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtjmI-0006m8-JO for submit@debbugs.gnu.org; Tue, 03 Nov 2015 17:10:07 -0500 Received: from mail.muc.de ([193.149.48.3]:44690) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ztjlv-0006lK-U5 for 17453@debbugs.gnu.org; Tue, 03 Nov 2015 17:10:03 -0500 Received: (qmail 71680 invoked by uid 3782); 3 Nov 2015 22:09:41 -0000 Received: from acm.muc.de (p5B14700A.dip0.t-ipconnect.de [91.20.112.10]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 03 Nov 2015 23:09:40 +0100 Received: (qmail 15080 invoked by uid 1000); 3 Nov 2015 22:11:31 -0000 Date: Tue, 3 Nov 2015 22:11:31 +0000 To: Artur Malabarba Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151103221131.GG2258@acm.fritz.box> References: <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> <20151103123116.GD2258@acm.fritz.box> <83a8qvw0aq.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: Eli Zaretskii , 17453@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Arturn. On Tue, Nov 03, 2015 at 04:18:45PM +0000, Artur Malabarba wrote: > 2015-11-03 15:49 GMT+00:00 Eli Zaretskii : > >> This is complicated. Ideally, the Follow Mode windows should be > >> synchronised in FM's post-command-hook, not isearch's. It is not > >> isearch's job to realign windows. follow-post-command-hook both realigns > >> windows and choses an appropriate window to put point in. We should let > >> it. > > Once again, if some code in Isearch calls the same function that is > > used in follow-post-command-hook, the above is not an issue. > > Moreover, saving some calls to the hook will make Emacs more > > responsive. > I agree with Eli and Juri on this. If there's a solution as simple as > calling a follow-mode function in isearch-post-update-hook, then this > sounds like a no-downside solution. I'm wondering if we're still talking about the same problem. ;-) A simpler solution is _not_ to call a FM function from that Isearch hook. Unless we're talking at cross purposes, there is simply no need. As long as the Isearch command is allowed to go to completion without forcibly redisplaying, FM will re-synchronise the windows (if needed) and select an appropriate window for point, all on its own (in follow-post-command-hook). > Of course it's not isearch's job to realign windows, but that's why > the hook exists: so that other packages can run their own functions > and do their own jobs at that point in time. Good night, and sleep well! -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 19:29:29 2015 Received: (at 17453) by debbugs.gnu.org; 4 Nov 2015 00:29:29 +0000 Received: from localhost ([127.0.0.1]:52003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtlxA-0001hi-Ix for submit@debbugs.gnu.org; Tue, 03 Nov 2015 19:29:29 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:54893 helo=homiemail-a75.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ztlx8-0001hZ-6p for 17453@debbugs.gnu.org; Tue, 03 Nov 2015 19:29:27 -0500 Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 2A1045EC072; Tue, 3 Nov 2015 16:29:25 -0800 (PST) Received: from localhost.linkov.net (85.253.169.191.cable.starman.ee [85.253.169.191]) (Authenticated sender: jurta@jurta.org) by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id DC6AE5EC07C; Tue, 3 Nov 2015 16:29:23 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Organization: LINKOV.NET References: <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> <20151103123116.GD2258@acm.fritz.box> <83a8qvw0aq.fsf@gnu.org> <20151103221131.GG2258@acm.fritz.box> Date: Wed, 04 Nov 2015 02:28:08 +0200 In-Reply-To: <20151103221131.GG2258@acm.fritz.box> (Alan Mackenzie's message of "Tue, 3 Nov 2015 22:11:31 +0000") Message-ID: <87mvuur4kn.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: Eli Zaretskii , 17453@debbugs.gnu.org, Artur Malabarba X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> >> This is complicated. Ideally, the Follow Mode windows should be >> >> synchronised in FM's post-command-hook, not isearch's. It is not >> >> isearch's job to realign windows. follow-post-command-hook both realigns >> >> windows and choses an appropriate window to put point in. We should let >> >> it. > >> > Once again, if some code in Isearch calls the same function that is >> > used in follow-post-command-hook, the above is not an issue. >> > Moreover, saving some calls to the hook will make Emacs more >> > responsive. > >> I agree with Eli and Juri on this. If there's a solution as simple as >> calling a follow-mode function in isearch-post-update-hook, then this >> sounds like a no-downside solution. > > I'm wondering if we're still talking about the same problem. ;-) A > simpler solution is _not_ to call a FM function from that Isearch hook. > Unless we're talking at cross purposes, there is simply no need. As > long as the Isearch command is allowed to go to completion without > forcibly redisplaying, FM will re-synchronise the windows (if needed) > and select an appropriate window for point, all on its own (in > follow-post-command-hook). It still might help to synchronise the windows from isearch-update-post-hook if we'll call it before calling isearch-lazy-highlight-new-loop with sit-for. I see no problem in changing the order of calls to isearch-update-post-hook and isearch-lazy-highlight-new-loop in isearch-update. Sure, follow-post-command-hook will be called twice but at least this simple solution for follow-mode doesn't require re-designing the whole lazy-highlighting machinery. diff --git a/lisp/follow.el b/lisp/follow.el index 938c59e..75c2788 100644 --- a/lisp/follow.el +++ b/lisp/follow.el @@ -420,6 +420,7 @@ (define-minor-mode follow-mode (if follow-mode (progn (add-hook 'compilation-filter-hook 'follow-align-compilation-windows t t) + (add-hook 'isearch-update-post-hook 'follow-post-command-hook t t) (add-hook 'post-command-hook 'follow-post-command-hook t) (add-hook 'window-size-change-functions 'follow-window-size-change t)) ;; Remove globally-installed hook functions only if there is no @@ -432,6 +433,7 @@ (define-minor-mode follow-mode (unless following (remove-hook 'post-command-hook 'follow-post-command-hook) (remove-hook 'window-size-change-functions 'follow-window-size-change))) + (remove-hook 'isearch-update-post-hook 'follow-post-command-hook t) (remove-hook 'compilation-filter-hook 'follow-align-compilation-windows t))) (defun follow-find-file-hook () diff --git a/lisp/isearch.el b/lisp/isearch.el index b762884..1e4a1a5 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -1011,12 +1011,12 @@ (defun isearch-update () (setq ;; quit-flag nil not for isearch-mode isearch-adjusted nil isearch-yank-flag nil) - (when isearch-lazy-highlight - (isearch-lazy-highlight-new-loop)) ;; We must prevent the point moving to the end of composition when a ;; part of the composition has just been searched. (setq disable-point-adjustment t) - (run-hooks 'isearch-update-post-hook)) + (run-hooks 'isearch-update-post-hook) + (when isearch-lazy-highlight + (isearch-lazy-highlight-new-loop))) (defun isearch-done (&optional nopush edit) "Exit Isearch mode. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 04 03:59:21 2015 Received: (at 17453) by debbugs.gnu.org; 4 Nov 2015 08:59:21 +0000 Received: from localhost ([127.0.0.1]:52232 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zttub-0000fs-2E for submit@debbugs.gnu.org; Wed, 04 Nov 2015 03:59:21 -0500 Received: from mail.muc.de ([193.149.48.3]:55194) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZttuZ-0000fj-2W for 17453@debbugs.gnu.org; Wed, 04 Nov 2015 03:59:20 -0500 Received: (qmail 46245 invoked by uid 3782); 4 Nov 2015 08:59:16 -0000 Received: from acm.muc.de (p5B147F06.dip0.t-ipconnect.de [91.20.127.6]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 04 Nov 2015 09:59:15 +0100 Received: (qmail 2400 invoked by uid 1000); 4 Nov 2015 09:01:06 -0000 Date: Wed, 4 Nov 2015 09:01:06 +0000 To: Juri Linkov Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151104090106.GA1736@acm.fritz.box> References: <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> <20151103123116.GD2258@acm.fritz.box> <83a8qvw0aq.fsf@gnu.org> <20151103221131.GG2258@acm.fritz.box> <87mvuur4kn.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mvuur4kn.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: Eli Zaretskii , 17453@debbugs.gnu.org, Artur Malabarba X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Juri. On Wed, Nov 04, 2015 at 02:28:08AM +0200, Juri Linkov wrote: > >> >> This is complicated. Ideally, the Follow Mode windows should be > >> >> synchronised in FM's post-command-hook, not isearch's. It is not > >> >> isearch's job to realign windows. follow-post-command-hook both realigns > >> >> windows and choses an appropriate window to put point in. We should let > >> >> it. > >> > Once again, if some code in Isearch calls the same function that is > >> > used in follow-post-command-hook, the above is not an issue. > >> > Moreover, saving some calls to the hook will make Emacs more > >> > responsive. > >> I agree with Eli and Juri on this. If there's a solution as simple as > >> calling a follow-mode function in isearch-post-update-hook, then this > >> sounds like a no-downside solution. > > I'm wondering if we're still talking about the same problem. ;-) A > > simpler solution is _not_ to call a FM function from that Isearch hook. > > Unless we're talking at cross purposes, there is simply no need. As > > long as the Isearch command is allowed to go to completion without > > forcibly redisplaying, FM will re-synchronise the windows (if needed) > > and select an appropriate window for point, all on its own (in > > follow-post-command-hook). > It still might help to synchronise the windows from isearch-update-post-hook > if we'll call it before calling isearch-lazy-highlight-new-loop with sit-for. I still say, wait until we really need it before we do anything so drastic. As Eli noted, follow-post-command-hook is SLOW, SLOW, SLOW. If we call it twice per command, it will be twice as slow. Also, why is the "(sit-for 0)" there at all? As its comment says, It is there for one purpose, and one purpose only: it is so that (window-start) is valid, and the check (not (= (window-start) isearch-lazy-highlight-window-start)) will work. This check means exactly "has the window scrolled?". > I see no problem in changing the order of calls to isearch-update-post-hook and > isearch-lazy-highlight-new-loop in isearch-update. Sure, follow-post-command-hook > will be called twice but at least this simple solution for follow-mode > doesn't require re-designing the whole lazy-highlighting machinery. In one of my mails yesterday, I proposed removing the (sit-for 0) and replacing this check on (window-start) with (redisplay-would-scroll-window-p) . This would fix the bug without any further changes. It would avoid any far reaching change in design of the lazy highlighting, avoid calling follow-post-command-hook twice, yet would work. > diff --git a/lisp/follow.el b/lisp/follow.el > index 938c59e..75c2788 100644 > --- a/lisp/follow.el > +++ b/lisp/follow.el > @@ -420,6 +420,7 @@ (define-minor-mode follow-mode > (if follow-mode > (progn > (add-hook 'compilation-filter-hook 'follow-align-compilation-windows t t) > + (add-hook 'isearch-update-post-hook 'follow-post-command-hook t t) > (add-hook 'post-command-hook 'follow-post-command-hook t) > (add-hook 'window-size-change-functions 'follow-window-size-change t)) > ;; Remove globally-installed hook functions only if there is no > @@ -432,6 +433,7 @@ (define-minor-mode follow-mode > (unless following > (remove-hook 'post-command-hook 'follow-post-command-hook) > (remove-hook 'window-size-change-functions 'follow-window-size-change))) > + (remove-hook 'isearch-update-post-hook 'follow-post-command-hook t) > (remove-hook 'compilation-filter-hook 'follow-align-compilation-windows t))) > (defun follow-find-file-hook () > diff --git a/lisp/isearch.el b/lisp/isearch.el > index b762884..1e4a1a5 100644 > --- a/lisp/isearch.el > +++ b/lisp/isearch.el > @@ -1011,12 +1011,12 @@ (defun isearch-update () > (setq ;; quit-flag nil not for isearch-mode > isearch-adjusted nil > isearch-yank-flag nil) > - (when isearch-lazy-highlight > - (isearch-lazy-highlight-new-loop)) > ;; We must prevent the point moving to the end of composition when a > ;; part of the composition has just been searched. > (setq disable-point-adjustment t) > - (run-hooks 'isearch-update-post-hook)) > + (run-hooks 'isearch-update-post-hook) > + (when isearch-lazy-highlight > + (isearch-lazy-highlight-new-loop))) > (defun isearch-done (&optional nopush edit) > "Exit Isearch mode. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 04 05:17:15 2015 Received: (at 17453) by debbugs.gnu.org; 4 Nov 2015 10:17:15 +0000 Received: from localhost ([127.0.0.1]:52301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ztv7y-0002VI-7s for submit@debbugs.gnu.org; Wed, 04 Nov 2015 05:17:14 -0500 Received: from mail-lb0-f173.google.com ([209.85.217.173]:32926) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ztv7u-0002V8-Of for 17453@debbugs.gnu.org; Wed, 04 Nov 2015 05:17:12 -0500 Received: by lbbkw15 with SMTP id kw15so6796021lbb.0 for <17453@debbugs.gnu.org>; Wed, 04 Nov 2015 02:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=k+K/O3YfWrN4QqKM2myA9/JXuMr6pZpTK9LxTiaFdgk=; b=v+KbraQ7WP/G86tVkLvwGvIsnWtFmRevS0nulx85xRHOYaP++2hxcWq2DFOR2t3ptu IlQ8cWyx4yjEKodaukuW1jVM4XKuC98jQqcrVJ+tMr1j/KdedLcFsYVHmXzAVKG3VS5o diI/wkbzMqWEF3ch5yl+GqsBp4JGCBim38dp3zLV5sfjTpcESv2txKalVNMk1UnZCTJe urFyV2xNH+UuCvT8sP9wO2FojL58Oon0RPQxw274eSyBqLOuNLEmUjA8bKTGB5DvSSzb ftnxCf7004i/MzVDoY9GPIYMveXii+ecVoUsuxVVZQtqnMhDTFRiJkj1Ny4eEzMza2ET /aUg== MIME-Version: 1.0 X-Received: by 10.112.235.65 with SMTP id uk1mr505511lbc.118.1446632229968; Wed, 04 Nov 2015 02:17:09 -0800 (PST) Received: by 10.112.63.71 with HTTP; Wed, 4 Nov 2015 02:17:09 -0800 (PST) In-Reply-To: <20151104090106.GA1736@acm.fritz.box> References: <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> <20151103123116.GD2258@acm.fritz.box> <83a8qvw0aq.fsf@gnu.org> <20151103221131.GG2258@acm.fritz.box> <87mvuur4kn.fsf@mail.linkov.net> <20151104090106.GA1736@acm.fritz.box> Date: Wed, 4 Nov 2015 10:17:09 +0000 X-Google-Sender-Auth: 9sgsRkpjU817Zz2OI4OGHFMk4ek Message-ID: Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. From: Artur Malabarba To: Alan Mackenzie Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: Eli Zaretskii , 17453@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bruce.connor.am@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 2015-11-04 9:01 GMT+00:00 Alan Mackenzie : >> It still might help to synchronise the windows from isearch-update-post-hook >> if we'll call it before calling isearch-lazy-highlight-new-loop with sit-for. > > I still say, wait until we really need it before we do anything so > drastic. As Eli noted, follow-post-command-hook is SLOW, SLOW, SLOW. > If we call it twice per command, it will be twice as slow. > > Also, why is the "(sit-for 0)" there at all? As its comment says, It > is there for one purpose, and one purpose only: it is so that > (window-start) is valid, and the check > > (not (= (window-start) > isearch-lazy-highlight-window-start)) > > will work. This check means exactly "has the window scrolled?" Have you tested redisplay-would-scroll-window-p in a fully folded org-mode buffer with 100 headlines where each headline has 100 lines of content? If you report that it works in this context and isn't slow then I'm ok with going with this solution. Like I said, as long as it doesn't cause regressions, this would be a fine refactoring to do in isearch.el. So we might as well apply it now and give any possible issues some time to surface (isearch is used by tons of people, so I'm sure they'll surface if any exist). While you're at it, if you could also refactor all those `(not (equal ...))' tests into a single `isearch--lazy-highlight-needs-update-p' function that would be very welcome (and if you do, do it as a separate commit before everything else so the other stuff is easy to revert separately). And if it looks like I'm saying "I'm fine with this" to everything here, that's because I am. It sounds like we're debating two fine options and bordering on bikeshedding. So I say: merge one and see how it goes. Cheers From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 05 07:36:45 2015 Received: (at 17453) by debbugs.gnu.org; 5 Nov 2015 12:36:46 +0000 Received: from localhost ([127.0.0.1]:54263 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZuJmX-0002OL-DW for submit@debbugs.gnu.org; Thu, 05 Nov 2015 07:36:45 -0500 Received: from mail.muc.de ([193.149.48.3]:34524) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZuJmU-0002OB-W3 for 17453@debbugs.gnu.org; Thu, 05 Nov 2015 07:36:43 -0500 Received: (qmail 62300 invoked by uid 3782); 5 Nov 2015 12:36:40 -0000 Received: from acm.muc.de (p5B1477AD.dip0.t-ipconnect.de [91.20.119.173]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 05 Nov 2015 13:36:40 +0100 Received: (qmail 3405 invoked by uid 1000); 5 Nov 2015 12:38:27 -0000 Date: Thu, 5 Nov 2015 12:38:27 +0000 To: Artur Malabarba Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151105123827.GA2887@acm.fritz.box> References: <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> <20151103123116.GD2258@acm.fritz.box> <83a8qvw0aq.fsf@gnu.org> <20151103221131.GG2258@acm.fritz.box> <87mvuur4kn.fsf@mail.linkov.net> <20151104090106.GA1736@acm.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: Eli Zaretskii , 17453@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Artur. On Wed, Nov 04, 2015 at 10:17:09AM +0000, Artur Malabarba wrote: > 2015-11-04 9:01 GMT+00:00 Alan Mackenzie : > >> It still might help to synchronise the windows from isearch-update-post-hook > >> if we'll call it before calling isearch-lazy-highlight-new-loop with sit-for. > > I still say, wait until we really need it before we do anything so > > drastic. As Eli noted, follow-post-command-hook is SLOW, SLOW, SLOW. > > If we call it twice per command, it will be twice as slow. > > Also, why is the "(sit-for 0)" there at all? As its comment says, It > > is there for one purpose, and one purpose only: it is so that > > (window-start) is valid, and the check > > (not (= (window-start) > > isearch-lazy-highlight-window-start)) > > will work. This check means exactly "has the window scrolled?" > Have you tested redisplay-would-scroll-window-p in a fully folded > org-mode buffer with 100 headlines where each headline has 100 lines > of content? Of course not. :-) By the way, what does Isearch do with such org-mode folded buffer? Does it unfold the content, ever? > If you report that it works in this context and isn't slow then I'm ok > with going with this solution. Like I said, as long as it doesn't > cause regressions, this would be a fine refactoring to do in > isearch.el. So we might as well apply it now and give any possible > issues some time to surface (isearch is used by tons of people, so I'm > sure they'll surface if any exist). > While you're at it, if you could also refactor all those `(not (equal > ...))' tests into a single `isearch--lazy-highlight-needs-update-p' > function that would be very welcome (and if you do, do it as a > separate commit before everything else so the other stuff is easy to > revert separately). I don't agree this is a good idea. At the moment, all these tests are in the same not too big defun that sets them. This kind of keeps things together - for instance if a new test was to be introduced, only this one function would need amending. > And if it looks like I'm saying "I'm fine with this" to everything > here, that's because I am. It sounds like we're debating two fine > options and bordering on bikeshedding. So I say: merge one and see how > it goes. I'm pretty much ready to do this. But maybe you could answer my question about unfolding org-mode buffers above, first. Thanks! > Cheers -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 05 12:13:33 2015 Received: (at 17453) by debbugs.gnu.org; 5 Nov 2015 17:13:33 +0000 Received: from localhost ([127.0.0.1]:54888 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZuO6O-0000pa-Lb for submit@debbugs.gnu.org; Thu, 05 Nov 2015 12:13:33 -0500 Received: from mail-lb0-f170.google.com ([209.85.217.170]:36652) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZuO64-0000p6-3u for 17453@debbugs.gnu.org; Thu, 05 Nov 2015 12:13:30 -0500 Received: by lbblt2 with SMTP id lt2so21244752lbb.3 for <17453@debbugs.gnu.org>; Thu, 05 Nov 2015 09:13:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BtbU5towa1XM5yfmzDy5J1Plf3u3pANlFVrFTAgMCdc=; b=mDa26EpOpBjZ/CkTSPuZ7jtjfcuCq62ZkgBQoIs9OSkpUYjx/cey2ukZKEvdp3v1b4 24rZcmxIYihL/W4XMR/zKBvJLgdOuTJJTMkmWqmHVsd9qknBAZyPKz9wLGspEJ/xkEzS mWGL9jDu6MX4HCqnG4KL62uyAf/xLGbMoS60NnAeSiMiiltIOGlfJMvghDvd3es2uhPw sbrDyD3dbm/Lo+P/QBqPlHIFAMAWvN4BpQkPxT5v/QqLxga/jUGWlUphl+JShYhYFPz1 ejuqOMbNniWguYdcWm8OU7mBJDMTLqJPChE2OG+PK5Yo1JzE9VSSQOBhmqz/yGEg5V7V R/dw== MIME-Version: 1.0 X-Received: by 10.112.62.232 with SMTP id b8mr4449906lbs.27.1446743591298; Thu, 05 Nov 2015 09:13:11 -0800 (PST) Received: by 10.112.63.70 with HTTP; Thu, 5 Nov 2015 09:13:11 -0800 (PST) In-Reply-To: <20151105123827.GA2887@acm.fritz.box> References: <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> <20151103123116.GD2258@acm.fritz.box> <83a8qvw0aq.fsf@gnu.org> <20151103221131.GG2258@acm.fritz.box> <87mvuur4kn.fsf@mail.linkov.net> <20151104090106.GA1736@acm.fritz.box> <20151105123827.GA2887@acm.fritz.box> Date: Thu, 5 Nov 2015 17:13:11 +0000 X-Google-Sender-Auth: e7AlZGrpsrJ7HUl4PquUjlNwMtE Message-ID: Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. From: Artur Malabarba To: Alan Mackenzie Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: Eli Zaretskii , 17453@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bruce.connor.am@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> Have you tested redisplay-would-scroll-window-p in a fully folded >> org-mode buffer with 100 headlines where each headline has 100 lines >> of content? > > Of course not. :-) > > By the way, what does Isearch do with such org-mode folded buffer? Does > it unfold the content, ever? Isearch has an option for that. By default it searches inside hidden text, and reveals the hidden text if the match is in there. But that's not why I asked. The 'count-screen-lines' function can be horribly slow on a large number of lines. I just want to check whether 'move-to-window-line' doesn't suffer from the same issue. A huge org buffer with lots of folded headlines is just a common cause of slowness for `count-screen-lines' because small visual movements could mean very large actual movements. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 07 07:58:01 2015 Received: (at 17453) by debbugs.gnu.org; 7 Nov 2015 12:58:02 +0000 Received: from localhost ([127.0.0.1]:56517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zv34D-0000hz-FS for submit@debbugs.gnu.org; Sat, 07 Nov 2015 07:58:01 -0500 Received: from mail.muc.de ([193.149.48.3]:34476) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zv33t-0000hX-5M for 17453@debbugs.gnu.org; Sat, 07 Nov 2015 07:58:00 -0500 Received: (qmail 6721 invoked by uid 3782); 7 Nov 2015 12:57:39 -0000 Received: from acm.muc.de (p579E81AA.dip0.t-ipconnect.de [87.158.129.170]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 07 Nov 2015 13:57:37 +0100 Received: (qmail 2836 invoked by uid 1000); 7 Nov 2015 12:59:31 -0000 Date: Sat, 7 Nov 2015 12:59:31 +0000 To: Juri Linkov Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151107125931.GA1770@acm.fritz.box> References: <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> <20151103123116.GD2258@acm.fritz.box> <83a8qvw0aq.fsf@gnu.org> <20151103221131.GG2258@acm.fritz.box> <87mvuur4kn.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mvuur4kn.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: Eli Zaretskii , 17453@debbugs.gnu.org, Artur Malabarba X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Juri, Artur, Eli. On Wed, Nov 04, 2015 at 02:28:08AM +0200, Juri Linkov wrote: > >> >> This is complicated. Ideally, the Follow Mode windows should be > >> >> synchronised in FM's post-command-hook, not isearch's. It is not > >> >> isearch's job to realign windows. follow-post-command-hook both realigns > >> >> windows and choses an appropriate window to put point in. We should let > >> >> it. > >> > Once again, if some code in Isearch calls the same function that is > >> > used in follow-post-command-hook, the above is not an issue. > >> > Moreover, saving some calls to the hook will make Emacs more > >> > responsive. > >> I agree with Eli and Juri on this. If there's a solution as simple as > >> calling a follow-mode function in isearch-post-update-hook, then this > >> sounds like a no-downside solution. > > I'm wondering if we're still talking about the same problem. ;-) A > > simpler solution is _not_ to call a FM function from that Isearch hook. > > Unless we're talking at cross purposes, there is simply no need. As > > long as the Isearch command is allowed to go to completion without > > forcibly redisplaying, FM will re-synchronise the windows (if needed) > > and select an appropriate window for point, all on its own (in > > follow-post-command-hook). > It still might help to synchronise the windows from isearch-update-post-hook > if we'll call it before calling isearch-lazy-highlight-new-loop with sit-for. > I see no problem in changing the order of calls to isearch-update-post-hook and > isearch-lazy-highlight-new-loop in isearch-update. Sure, follow-post-command-hook > will be called twice but at least this simple solution for follow-mode > doesn't require re-designing the whole lazy-highlighting machinery. The discussion of this bug seems to have stalled. I'd very much like to decide all the issues now, and to fix (this part of) this bug. Bug summary: With follow mode active, and lazy highliting active, forward Isearch scrolls the left hand window when it should instead move to to the right hand window. Immediate cause: the form "(sit-for 0)" in isearch-lazy-highlight-new-loop scrolls the window before Follow Mode has had a chance to resynchronise everything. Proposed solutions: 1. Call follow-post-command-hook from isearch-update before calling isearch-lazy-highlight-new-loop (as described above). 2. Call the proposed function `redisplay-would-scroll-window' instead of the `sit-for'. 3. Make isearch-lazy-highlight-new-loop always set the idle timer, and test for the need for a new loop instead in the function it triggers. Remove the `sit-for'. I now think solution 2. is not sensible or realistic. Redisplay is just too complicated to second-guess. Solution 1. has the disadvantage that follow-post-command-hook would be called twice for every command in Isearch. It is not fast. Solution 3. similarly might have the problem that if lazy-highlight-initial-delay is set to zero, redisplay might not have done its work when isearch-lazy-highlight-update runs. (I haven't tried it out, yet). Personally, I am in favour of solution 3, but I'm willing to be persuaded into solution 1. But I'd like us to come to a decision quickly. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 07 08:39:01 2015 Received: (at 17453) by debbugs.gnu.org; 7 Nov 2015 13:39:01 +0000 Received: from localhost ([127.0.0.1]:56571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zv3hs-0001h6-TD for submit@debbugs.gnu.org; Sat, 07 Nov 2015 08:39:01 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:63817) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zv3hX-0001ga-Hy for 17453@debbugs.gnu.org; Sat, 07 Nov 2015 08:38:59 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NXG00A005UD8200@a-mtaout20.012.net.il> for 17453@debbugs.gnu.org; Sat, 07 Nov 2015 15:38:37 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXG00A4P5WD2W40@a-mtaout20.012.net.il>; Sat, 07 Nov 2015 15:38:37 +0200 (IST) Date: Sat, 07 Nov 2015 15:38:31 +0200 From: Eli Zaretskii Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. In-reply-to: <20151107125931.GA1770@acm.fritz.box> X-012-Sender: halo1@inter.net.il To: Alan Mackenzie Message-id: <83oaf6oroo.fsf@gnu.org> References: <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> <20151103123116.GD2258@acm.fritz.box> <83a8qvw0aq.fsf@gnu.org> <20151103221131.GG2258@acm.fritz.box> <87mvuur4kn.fsf@mail.linkov.net> <20151107125931.GA1770@acm.fritz.box> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, bruce.connor.am@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 7 Nov 2015 12:59:31 +0000 > Cc: Artur Malabarba , Eli Zaretskii , > 17453@debbugs.gnu.org > From: Alan Mackenzie > > Proposed solutions: > 1. Call follow-post-command-hook from isearch-update before calling > isearch-lazy-highlight-new-loop (as described above). > 2. Call the proposed function `redisplay-would-scroll-window' instead of > the `sit-for'. > 3. Make isearch-lazy-highlight-new-loop always set the idle timer, and > test for the need for a new loop instead in the function it triggers. > Remove the `sit-for'. > > I now think solution 2. is not sensible or realistic. Redisplay is just > too complicated to second-guess. > > Solution 1. has the disadvantage that follow-post-command-hook would be > called twice for every command in Isearch. It is not fast. > > Solution 3. similarly might have the problem that if > lazy-highlight-initial-delay is set to zero, redisplay might not have > done its work when isearch-lazy-highlight-update runs. (I haven't tried > it out, yet). > > Personally, I am in favour of solution 3, but I'm willing to be persuaded > into solution 1. But I'd like us to come to a decision quickly. How about using 1), but also adding some indication that could prevent the post-command-hook from being called twice? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 08 05:30:44 2015 Received: (at 17453) by debbugs.gnu.org; 8 Nov 2015 10:30:44 +0000 Received: from localhost ([127.0.0.1]:57276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZvNFD-0008UV-QR for submit@debbugs.gnu.org; Sun, 08 Nov 2015 05:30:44 -0500 Received: from mail.muc.de ([193.149.48.3]:58096) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZvNFA-0008UM-Hf for 17453@debbugs.gnu.org; Sun, 08 Nov 2015 05:30:41 -0500 Received: (qmail 38584 invoked by uid 3782); 8 Nov 2015 10:30:38 -0000 Received: from acm.muc.de (p548A4846.dip0.t-ipconnect.de [84.138.72.70]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 08 Nov 2015 11:30:37 +0100 Received: (qmail 2072 invoked by uid 1000); 8 Nov 2015 10:32:32 -0000 Date: Sun, 8 Nov 2015 10:32:32 +0000 To: Eli Zaretskii Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Message-ID: <20151108103231.GA1962@acm.fritz.box> References: <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> <20151103123116.GD2258@acm.fritz.box> <83a8qvw0aq.fsf@gnu.org> <20151103221131.GG2258@acm.fritz.box> <87mvuur4kn.fsf@mail.linkov.net> <20151107125931.GA1770@acm.fritz.box> <83oaf6oroo.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83oaf6oroo.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, bruce.connor.am@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Eli. On Sat, Nov 07, 2015 at 03:38:31PM +0200, Eli Zaretskii wrote: > > Date: Sat, 7 Nov 2015 12:59:31 +0000 > > Cc: Artur Malabarba , Eli Zaretskii , > > 17453@debbugs.gnu.org > > From: Alan Mackenzie > > Proposed solutions: > > 1. Call follow-post-command-hook from isearch-update before calling > > isearch-lazy-highlight-new-loop (as described above). > > 2. Call the proposed function `redisplay-would-scroll-window' instead of > > the `sit-for'. > > 3. Make isearch-lazy-highlight-new-loop always set the idle timer, and > > test for the need for a new loop instead in the function it triggers. > > Remove the `sit-for'. > > I now think solution 2. is not sensible or realistic. Redisplay is just > > too complicated to second-guess. > > Solution 1. has the disadvantage that follow-post-command-hook would be > > called twice for every command in Isearch. It is not fast. > > Solution 3. similarly might have the problem that if > > lazy-highlight-initial-delay is set to zero, redisplay might not have > > done its work when isearch-lazy-highlight-update runs. (I haven't tried > > it out, yet). > > Personally, I am in favour of solution 3, but I'm willing to be persuaded > > into solution 1. But I'd like us to come to a decision quickly. > How about using 1), but also adding some indication that could prevent > the post-command-hook from being called twice? Hmm. Such artifices are not pretty. Such a flag would have to be set in isearch.el just after isearch-update-post-hook (which calls follow-post-command-hook) has been invoked. Something would have to clear it, perhaps something at the end of the lazy highlight loop. Also, this would couple Isearch and Follow Mode undesirably: Isearch really shouldn't have to know anything about the FM window setup. Or, maybe just letting follow-post-command-hook run twice wouldn't be too bad. The second time, all the windows would already be synchronised and point would be in the right window. I've had a look at the code, and it seems in this situation it actually does call the function to rearrange the windows. Maybe that is a bug which might be fixed. Do you have any views on solution 3? -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 08 20:16:59 2015 Received: (at 17453) by debbugs.gnu.org; 9 Nov 2015 01:16:59 +0000 Received: from localhost ([127.0.0.1]:57989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zvb4s-0003J2-NS for submit@debbugs.gnu.org; Sun, 08 Nov 2015 20:16:59 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:37783 helo=homiemail-a23.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zvb4X-0003IY-PY for 17453@debbugs.gnu.org; Sun, 08 Nov 2015 20:16:57 -0500 Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id EFFC54B0063; Sun, 8 Nov 2015 17:16:35 -0800 (PST) Received: from localhost.linkov.net (m212-53-104-68.cust.tele2.ee [212.53.104.68]) (Authenticated sender: jurta@jurta.org) by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id CDF7B4B0058; Sun, 8 Nov 2015 17:16:34 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: Framework extending window functions for Follow Mode (etc.). Organization: LINKOV.NET References: <20151105192905.GA7986@acm.fritz.box> <20151107182420.GA1774@acm.fritz.box> <871tc18oai.fsf@mail.linkov.net> <20151108002955.GC1774@acm.fritz.box> Date: Mon, 09 Nov 2015 02:50:04 +0200 In-Reply-To: <20151108002955.GC1774@acm.fritz.box> (Alan Mackenzie's message of "Sun, 8 Nov 2015 00:29:55 +0000") Message-ID: <8737wgou4z.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> >> I admit I am confused. I thought we had narrowed down three possible >> >> solutions to this issue (which you just listed over at the bug thread), all >> >> of which are simpler than this code. > >> > Those solutions are to merely one part of the bug, namely C-s wrongly >> > scrolling a window instead of moving onto the next one. > >> > The other parts of #17453 are: >> > 2: lazy highlighting is confined to one Follow Mode window (I'm a bit >> > confused as to the status of this, though); > >> This problem is already solved by enabling lazy-highlighting of the whole >> follow-mode buffer, but I postponed installing that patch to not create merge >> conflicts with your work in the same functions. > > My solution is to lazily highlight just the part visible in windows (but > in all pertinent windows). Isn't highlighting all of it going to be a > bit slow on a large buffer? It shouldn't be slow with a sufficiently low value of lazy-highlight-max-at-a-time. >> > 3: With isearch-allow-scroll enabled, it is not possible to scroll point >> > to the next or previous Follow Mode window; >> > , in addition to which I have a fix for ... > >> That's because isearch-post-command-hook uses isearch-pre-scroll-point >> to move it back, so it's possible to nullify isearch-pre-scroll-point >> in follow-mode, but I see that it leaves the highlighted found string >> at its old position because the isearch-allow-scroll feature doesn't support >> finding the next search hit after scrolling, or something like this >> that would make sense. IOW, this is a limitation of isearch-allow-scroll. > > In my personal copy of Emacs, I've had the isearch scrolling working > properly with Follow Mode for ~18 months. It was me that wrote the > isearch scrolling code in the first place, back in 2003. Yes, I remember, and appreciate your efforts to develop it further. > Part 3 of the bug is most assuredly NOT an intrinsic limitation of > isearch-allow-scroll. It's caused by the variables w-L1 and w-L-1, the > bounds for the permissible scrolling range in > isearch-string-out-of-window, being set to the top and botom of the > _single_ window. When these variables are set to the top of bottom of > the entire FM group of windows, the bug is solved. This requires my new > framework, or something like it. I tried to not use isearch-string-out-of-window/isearch-back-into-window at all, but I can't get a useful behavior in such situation of scrolling out of the window with the current search hit. Could you show how you see it should work in this case in follow-mode? >> > 4: With point near the bottom of a Follow Mode window, start an Isearch, >> > and repeatedly do M-s C-e, until the highlighted match continues on to >> > the next window. Continue doing M-s C-e until the string in the >> > minibuffer expands by a line. At this point the top of the RH window >> > gets spuriously scrolled into the middle of the window, leaving the FM >> > windows unsynchronised. > >> I see the same behavior even without Isearch. > > The buggy behaviour I've described is explicitly and essentially an > Isearch scenario. What do you mean by "the same behavior" and what > sequence of commands generates it? > > The solution to problem 4 involves making sure point is at the right > place at the right time when invoking isearch-message. I have made > changes to fix it. I meant such things as 'M-: (message "x\ny\nz") RET' causes jumping too. >> Honestly, I see here nothing that requires a new multi-window framework. > > I want these bugs to be solved. What, then, are the alternatives to > this framework (or something like it)? Isearch needs information about > the Follow Mode windows, or it can't work properly. > > So far, I've written three solutions for these bugs, as I outlined at > length in an email to Martin R. today. The first of these solutions was > (justifiably) rejected by Stefan because it was a quick and dirty fix, > and he explicitly requested the new framework that I have now built. > Eli didn't like the second attempt and explicitly suggested the way for > my third attempt. You and Martin dislike this most recent third > attempt. > > It seems to me I've spent more time discussing this bug on the bug list > and emacs-devel, and reformulating the fix, than actually tracking down > and fixing the bugs in the first place. At the moment I feel like I'm > trying to hack down a wall of constant negativity. I don't recall > anybody else saying positively they want this bug fixed, and I certainly > don't feel I've had much encouragement wrt this bug, in the last few > days and weeks. > > I see Follow Mode as being a critically important component of Emacs, > the more so since very wide (240 characters and more) screens displaced > the fairly narrow CRT monitors. I would like every Emacs user to be > able to use FM as easily as I can. Right at the moment there is no > suitable interface to FM for libraries that require to do their own > window manipulation. Such an interface is what Stefan wanted, and it's > what I want, too. As of yet, there's been practically no discussion of > this interface I've written, beyond Eli suggesting the current version > and John suggesting a name change for some hooks. > > So, where do we go from here? I would like these bugs fixed for 25.1. The problem is that you are trying to design a new framework, but not demonstrated yet how it would be useful generally in cases other than a specific combination of isearch/follow-mode. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 09 10:39:34 2015 Received: (at 17453) by debbugs.gnu.org; 9 Nov 2015 15:39:35 +0000 Received: from localhost ([127.0.0.1]:59373 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZvoXe-0001yN-0f for submit@debbugs.gnu.org; Mon, 09 Nov 2015 10:39:34 -0500 Received: from mail.muc.de ([193.149.48.3]:19202) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZvoXa-0001yC-Ns for 17453@debbugs.gnu.org; Mon, 09 Nov 2015 10:39:31 -0500 Received: (qmail 59124 invoked by uid 3782); 9 Nov 2015 15:39:29 -0000 Received: from acm.muc.de (p579E973C.dip0.t-ipconnect.de [87.158.151.60]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 09 Nov 2015 16:39:28 +0100 Received: (qmail 5701 invoked by uid 1000); 9 Nov 2015 15:41:24 -0000 Date: Mon, 9 Nov 2015 15:41:24 +0000 To: Juri Linkov Subject: Re: Framework extending window functions for Follow Mode (etc.). Message-ID: <20151109154124.GC2284@acm.fritz.box> References: <20151105192905.GA7986@acm.fritz.box> <20151107182420.GA1774@acm.fritz.box> <871tc18oai.fsf@mail.linkov.net> <20151108002955.GC1774@acm.fritz.box> <8737wgou4z.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8737wgou4z.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org, emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) Hello, Juri. On Mon, Nov 09, 2015 at 02:50:04AM +0200, Juri Linkov wrote: > >> This problem is already solved by enabling lazy-highlighting of the whole > >> follow-mode buffer, but I postponed installing that patch to not create merge > >> conflicts with your work in the same functions. > > My solution is to lazily highlight just the part visible in windows (but > > in all pertinent windows). Isn't highlighting all of it going to be a > > bit slow on a large buffer? > It shouldn't be slow with a sufficiently low value of lazy-highlight-max-at-a-time. OK, I see it: it would be slow if it had to go to completion, but any key/mouse/other event will terminate it. So the only place it might be a problem is somewhere where CPU cycles are at a premium. > > Part 3 of the bug is most assuredly NOT an intrinsic limitation of > > isearch-allow-scroll. It's caused by the variables w-L1 and w-L-1, the > > bounds for the permissible scrolling range in > > isearch-string-out-of-window, being set to the top and botom of the > > _single_ window. When these variables are set to the top of bottom of > > the entire FM group of windows, the bug is solved. This requires my new > > framework, or something like it. > I tried to not use isearch-string-out-of-window/isearch-back-into-window > at all, but I can't get a useful behavior in such situation of scrolling > out of the window with the current search hit. Could you show how you see > it should work in this case in follow-mode? To start with, set (global-set-key [next] 'follow-scroll-up) (global-set-key [prior] 'follow-scroll-down) (setq isearch-allow-scroll t) . Then start an Isearch not too close to the start of a buffer with Follow Mode enabled with at least two windows. Type something to get a search match highlighted. Now and should scroll that match between Follow Mode windows, the boundaries of that scrolling being the top of the LH window and the bottom of the RH window. To make this work properly, the four variables in isearch-string-out-of-window, w-start, w-end, w-L1, w-L-1, are set to the positions in the entire group of windows, by setting the proposed &optional argument GROUP to t in the calls to certain window functions, e.g. (let ((w-start (window-start nil t)) ^ > >> > 4: With point near the bottom of a Follow Mode window, start an Isearch, > >> > and repeatedly do M-s C-e, until the highlighted match continues on to > >> > the next window. Continue doing M-s C-e until the string in the > >> > minibuffer expands by a line. At this point the top of the RH window > >> > gets spuriously scrolled into the middle of the window, leaving the FM > >> > windows unsynchronised. > >> I see the same behavior even without Isearch. > > The buggy behaviour I've described is explicitly and essentially an > > Isearch scenario. What do you mean by "the same behavior" and what > > sequence of commands generates it? > > The solution to problem 4 involves making sure point is at the right > > place at the right time when invoking isearch-message. I have made > > changes to fix it. > I meant such things as 'M-: (message "x\ny\nz") RET' causes jumping too. It causes some scrolling of windows to keep them properly aligned when the echo area expands to three lines. This is expected and proper. However, when the echo area goes back to one line, the windows don't scroll back again, leaving them unaligned. I raised a bug for this this morning. It seems it is a known problem which is tricky to solve. > >> Honestly, I see here nothing that requires a new multi-window framework. > > I want these bugs to be solved. What, then, are the alternatives to > > this framework (or something like it)? Isearch needs information about > > the Follow Mode windows, or it can't work properly. [ .... ] > > So, where do we go from here? I would like these bugs fixed for 25.1. > The problem is that you are trying to design a new framework, > but not demonstrated yet how it would be useful generally in cases > other than a specific combination of isearch/follow-mode. Any elisp software which manipulates windows will be able to work better by considering entire FM groups. I did some grepping: here are some examples which the new framework could improve: `kill-ring-save' should blink the cursor on the matching other-end, if that is visible. With FM active, and other end being in a different window, currently it wrongly outputs a message instead. `window-screen-lines' could be enhanced (optionally) to return the number of screen lines in the entire group. `blink-matching-open' could be enhanced to handle FM windows properly. `ns-scroll-bar-move' (probably) should `set-window-start' for the entire window group. This (might) avoid scrolling such that the RH follow window is displaying empty space. One point about this new framework is that it is "harmless" in the sense that anything which worked (or failed to work) prior to it will continue unchanged unless specifically amended. It's disadvantage is that it adds a little to the bulk of things people need to know or to look up in manuals. I think Follow Mode should become easier to use, both for users and for hackers, especially given that wide screens (>200 characters) are now the norm rather than the exception. At the moment Follow Mode is ridiculously difficult to start (manually splitting windows, doing M-x follow-mode) and even more difficult to hack for - just what interfaces are currently available for making a package work with FM? Answer: none at all. This new framework is intended to go some way to closing the gap. The alternative to a framework is a bugfix which is specific to Isearch. Even this would require some sort of interface definition and abstraction. At a minimum, for "part 3" of the bug, Isearch would need somehow to obtain the bounds of the group of windows. The last alternative is a quick and dirty fix where Isearch would just call Follow Mode functions. I don't think anybody really wants this. Would it help if I actually made the source available? If so, where? I don't really think it would be appropriate to dump a patch of this size on emacs-devel, and the time to commit the changes to master has clearly not yet arrived. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 09 20:28:20 2015 Received: (at 17453) by debbugs.gnu.org; 10 Nov 2015 01:28:20 +0000 Received: from localhost ([127.0.0.1]:59591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZvxjP-0002MA-GO for submit@debbugs.gnu.org; Mon, 09 Nov 2015 20:28:20 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:36577 helo=homiemail-a101.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZvxjM-0002M1-SW for 17453@debbugs.gnu.org; Mon, 09 Nov 2015 20:28:17 -0500 Received: from homiemail-a101.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTP id 94FBC117E06C; Mon, 9 Nov 2015 17:28:13 -0800 (PST) Received: from localhost.linkov.net (m212-53-104-68.cust.tele2.ee [212.53.104.68]) (Authenticated sender: jurta@jurta.org) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTPA id 8A65A117E065; Mon, 9 Nov 2015 17:28:12 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: Framework extending window functions for Follow Mode (etc.). Organization: LINKOV.NET References: <20151105192905.GA7986@acm.fritz.box> <20151107182420.GA1774@acm.fritz.box> <871tc18oai.fsf@mail.linkov.net> <20151108002955.GC1774@acm.fritz.box> <8737wgou4z.fsf@mail.linkov.net> <20151109154124.GC2284@acm.fritz.box> Date: Tue, 10 Nov 2015 02:51:41 +0200 In-Reply-To: <20151109154124.GC2284@acm.fritz.box> (Alan Mackenzie's message of "Mon, 9 Nov 2015 15:41:24 +0000") Message-ID: <87611a8x96.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> I tried to not use isearch-string-out-of-window/isearch-back-into-window >> at all, but I can't get a useful behavior in such situation of scrolling >> out of the window with the current search hit. Could you show how you see >> it should work in this case in follow-mode? > > To start with, set > > (global-set-key [next] 'follow-scroll-up) > (global-set-key [prior] 'follow-scroll-down) > (setq isearch-allow-scroll t) > > . Then start an Isearch not too close to the start of a buffer with > Follow Mode enabled with at least two windows. Type something to get a > search match highlighted. Now and should scroll that > match between Follow Mode windows, the boundaries of that scrolling being > the top of the LH window and the bottom of the RH window. > > To make this work properly, the four variables in > isearch-string-out-of-window, w-start, w-end, w-L1, w-L-1, are set to the > positions in the entire group of windows, by setting the proposed > &optional argument GROUP to t in the calls to certain window functions, > e.g. > > (let ((w-start (window-start nil t)) > ^ Could you provide the shortest patch to test the behavior that you describe? For now I tried the following, is this what you want to generalise with a new framework? diff --git a/lisp/isearch.el b/lisp/isearch.el index b762884..3b61505 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -2237,10 +2237,19 @@ (defun isearch-string-out-of-window (isearch-point) together with as much of the search string as will fit; the symbol `above' if we need to scroll the text downwards; the symbol `below', if upwards." - (let ((w-start (window-start)) - (w-end (window-end nil t)) - (w-L1 (save-excursion (move-to-window-line 1) (point))) - (w-L-1 (save-excursion (move-to-window-line -1) (point))) + (let ((w-start (window-start (and (fboundp 'follow-all-followers) + (car (follow-all-followers))))) + (w-end (window-end (and (fboundp 'follow-all-followers) + (car (last (follow-all-followers)))) + t)) + (w-L1 (save-excursion + (when (fboundp 'follow-all-followers) + (select-window (car (follow-all-followers)))) + (move-to-window-line 1) (point))) + (w-L-1 (save-excursion + (when (fboundp 'follow-all-followers) + (select-window (car (last (follow-all-followers))))) + (move-to-window-line -1) (point))) start end) ; start and end of search string in buffer (if isearch-forward (setq end isearch-point start (or isearch-other-end isearch-point)) >> The problem is that you are trying to design a new framework, >> but not demonstrated yet how it would be useful generally in cases >> other than a specific combination of isearch/follow-mode. > > Any elisp software which manipulates windows will be able to work better > by considering entire FM groups. I did some grepping: here are some > examples which the new framework could improve: > > `kill-ring-save' should blink the cursor on the matching other-end, if > that is visible. With FM active, and other end being in a different > window, currently it wrongly outputs a message instead. > > `window-screen-lines' could be enhanced (optionally) to return the number > of screen lines in the entire group. > > `blink-matching-open' could be enhanced to handle FM windows properly. > > `ns-scroll-bar-move' (probably) should `set-window-start' for the entire > window group. This (might) avoid scrolling such that the RH follow > window is displaying empty space. > > > One point about this new framework is that it is "harmless" in the sense > that anything which worked (or failed to work) prior to it will continue > unchanged unless specifically amended. It's disadvantage is that it adds > a little to the bulk of things people need to know or to look up in > manuals. > > I think Follow Mode should become easier to use, both for users and for > hackers, especially given that wide screens (>200 characters) are now the > norm rather than the exception. At the moment Follow Mode is > ridiculously difficult to start (manually splitting windows, doing M-x > follow-mode) and even more difficult to hack for - just what interfaces > are currently available for making a package work with FM? Answer: none > at all. This new framework is intended to go some way to closing the > gap. > > The alternative to a framework is a bugfix which is specific to Isearch. > Even this would require some sort of interface definition and > abstraction. At a minimum, for "part 3" of the bug, Isearch would need > somehow to obtain the bounds of the group of windows. > > The last alternative is a quick and dirty fix where Isearch would just > call Follow Mode functions. I don't think anybody really wants this. > > Would it help if I actually made the source available? If so, where? I > don't really think it would be appropriate to dump a patch of this size > on emacs-devel, and the time to commit the changes to master has clearly > not yet arrived. You are trying to do everything at once. To successfully achieve your goals it would be much more clear for us to see the progress step by step, i.e. if at first you demonstrated how to fix the co-operation between Isearch and Follow Mode by a quick and dirty fix like in the patch above then we could see how well your fixes work, and also what places need generalisation, and how your new framework would be useful here and for other packages that might benefit from it. By such inductive method we could quickly arrive to a conclusion without much friction. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 10 06:06:50 2015 Received: (at 17453) by debbugs.gnu.org; 10 Nov 2015 11:06:50 +0000 Received: from localhost ([127.0.0.1]:59761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zw6lF-0000Cl-Px for submit@debbugs.gnu.org; Tue, 10 Nov 2015 06:06:50 -0500 Received: from mail.muc.de ([193.149.48.3]:49970) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zw6kv-0000CL-0e for 17453@debbugs.gnu.org; Tue, 10 Nov 2015 06:06:48 -0500 Received: (qmail 6679 invoked by uid 3782); 10 Nov 2015 11:06:27 -0000 Received: from acm.muc.de (p579E9232.dip0.t-ipconnect.de [87.158.146.50]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 10 Nov 2015 12:06:27 +0100 Received: (qmail 3043 invoked by uid 1000); 10 Nov 2015 11:08:24 -0000 Date: Tue, 10 Nov 2015 11:08:24 +0000 To: Juri Linkov Subject: Re: Framework extending window functions for Follow Mode (etc.). Message-ID: <20151110110823.GB2626@acm.fritz.box> References: <20151105192905.GA7986@acm.fritz.box> <20151107182420.GA1774@acm.fritz.box> <871tc18oai.fsf@mail.linkov.net> <20151108002955.GC1774@acm.fritz.box> <8737wgou4z.fsf@mail.linkov.net> <20151109154124.GC2284@acm.fritz.box> <87611a8x96.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87611a8x96.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) Hello, Juri. On Tue, Nov 10, 2015 at 02:51:41AM +0200, Juri Linkov wrote: > >> I tried to not use isearch-string-out-of-window/isearch-back-into-window > >> at all, but I can't get a useful behavior in such situation of scrolling > >> out of the window with the current search hit. Could you show how you see > >> it should work in this case in follow-mode? > > To start with, set > > (global-set-key [next] 'follow-scroll-up) > > (global-set-key [prior] 'follow-scroll-down) > > (setq isearch-allow-scroll t) > > . Then start an Isearch not too close to the start of a buffer with > > Follow Mode enabled with at least two windows. Type something to get a > > search match highlighted. Now and should scroll that > > match between Follow Mode windows, the boundaries of that scrolling being > > the top of the LH window and the bottom of the RH window. > > To make this work properly, the four variables in > > isearch-string-out-of-window, w-start, w-end, w-L1, w-L-1, are set to the > > positions in the entire group of windows, by setting the proposed > > &optional argument GROUP to t in the calls to certain window functions, > > e.g. > > (let ((w-start (window-start nil t)) > > ^ > Could you provide the shortest patch to test the behavior that you describe? Can I ask you here to look at the initial patch in the archive for bug #17453 (see below)? > For now I tried the following, is this what you want to generalise with > a new framework? More or less, yes. > diff --git a/lisp/isearch.el b/lisp/isearch.el > index b762884..3b61505 100644 > --- a/lisp/isearch.el > +++ b/lisp/isearch.el > @@ -2237,10 +2237,19 @@ (defun isearch-string-out-of-window (isearch-point) > together with as much of the search string as will fit; the symbol > `above' if we need to scroll the text downwards; the symbol `below', > if upwards." > - (let ((w-start (window-start)) > - (w-end (window-end nil t)) > - (w-L1 (save-excursion (move-to-window-line 1) (point))) > - (w-L-1 (save-excursion (move-to-window-line -1) (point))) > + (let ((w-start (window-start (and (fboundp 'follow-all-followers) > + (car (follow-all-followers))))) > + (w-end (window-end (and (fboundp 'follow-all-followers) > + (car (last (follow-all-followers)))) > + t)) > + (w-L1 (save-excursion > + (when (fboundp 'follow-all-followers) > + (select-window (car (follow-all-followers)))) > + (move-to-window-line 1) (point))) > + (w-L-1 (save-excursion > + (when (fboundp 'follow-all-followers) > + (select-window (car (last (follow-all-followers))))) > + (move-to-window-line -1) (point))) > start end) ; start and end of search string in buffer > (if isearch-forward > (setq end isearch-point start (or isearch-other-end isearch-point)) As a small point, I think you'd want a `save-selected-window' around the forms which bind w-L1 and w-L-1. [ .... ] > > The last alternative is a quick and dirty fix where Isearch would just > > call Follow Mode functions. I don't think anybody really wants this. > > Would it help if I actually made the source available? If so, where? I > > don't really think it would be appropriate to dump a patch of this size > > on emacs-devel, and the time to commit the changes to master has clearly > > not yet arrived. > You are trying to do everything at once. To successfully achieve your goals > it would be much more clear for us to see the progress step by step, i.e. > if at first you demonstrated how to fix the co-operation between Isearch and > Follow Mode by a quick and dirty fix like in the patch above then we could see > how well your fixes work, and also what places need generalisation, > and how your new framework would be useful here and for other packages > that might benefit from it. I posted the quick and dirty fix on 2014-05-09 in the opening post for bug #17453 (the bug which is still current and has around 55 posts). This post is, naturally, still available on http://debbugs.gnu.org. I was encouraged by Stefan instead to formulate the change as a more general framework, removing the direct access to follow-mode.el from isearch.el. I first posted a description of the framework on 2015-10-29, in the bug #17453 thread. This was criticised by Eli, and I amended it substantially in response. > By such inductive method we could quickly arrive to a conclusion > without much friction. I posted the essence of the framework, as it now is, in a (cut down) patch at the beginning of this thread. I have complete patches for both the framework and isearch.el available. Together, they are really too big to post on emacs-devel. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 10 19:36:57 2015 Received: (at 17453) by debbugs.gnu.org; 11 Nov 2015 00:36:57 +0000 Received: from localhost ([127.0.0.1]:60758 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZwJPE-0005cv-Ry for submit@debbugs.gnu.org; Tue, 10 Nov 2015 19:36:57 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:42627 helo=homiemail-a101.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZwJPC-0005cm-IY for 17453@debbugs.gnu.org; Tue, 10 Nov 2015 19:36:55 -0500 Received: from homiemail-a101.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTP id 6C7E1117E06C; Tue, 10 Nov 2015 16:36:53 -0800 (PST) Received: from localhost.linkov.net (m212-53-104-68.cust.tele2.ee [212.53.104.68]) (Authenticated sender: jurta@jurta.org) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTPA id 6E106117E065; Tue, 10 Nov 2015 16:36:52 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: Framework extending window functions for Follow Mode (etc.). Organization: LINKOV.NET References: <20151105192905.GA7986@acm.fritz.box> <20151107182420.GA1774@acm.fritz.box> <871tc18oai.fsf@mail.linkov.net> <20151108002955.GC1774@acm.fritz.box> <8737wgou4z.fsf@mail.linkov.net> <20151109154124.GC2284@acm.fritz.box> <87611a8x96.fsf@mail.linkov.net> <20151110110823.GB2626@acm.fritz.box> Date: Wed, 11 Nov 2015 02:12:17 +0200 In-Reply-To: <20151110110823.GB2626@acm.fritz.box> (Alan Mackenzie's message of "Tue, 10 Nov 2015 11:08:24 +0000") Message-ID: <876119s7fu.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > Can I ask you here to look at the initial patch in the archive for bug > #17453 (see below)? Thanks, I see. > I posted the essence of the framework, as it now is, in a (cut down) > patch at the beginning of this thread. I have complete patches for both > the framework and isearch.el available. Together, they are really too > big to post on emacs-devel. Could you put them on a branch then? From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 11 11:17:22 2015 Received: (at 17453) by debbugs.gnu.org; 11 Nov 2015 16:17:22 +0000 Received: from localhost ([127.0.0.1]:33475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZwY5J-00068w-MM for submit@debbugs.gnu.org; Wed, 11 Nov 2015 11:17:21 -0500 Received: from mail.muc.de ([193.149.48.3]:60685) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZwY5H-00068m-05 for 17453@debbugs.gnu.org; Wed, 11 Nov 2015 11:17:19 -0500 Received: (qmail 43274 invoked by uid 3782); 11 Nov 2015 16:17:18 -0000 Received: from acm.muc.de (p548A5911.dip0.t-ipconnect.de [84.138.89.17]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 11 Nov 2015 17:17:17 +0100 Received: (qmail 5881 invoked by uid 1000); 11 Nov 2015 16:19:14 -0000 Date: Wed, 11 Nov 2015 16:19:14 +0000 To: Juri Linkov Subject: Re: Framework extending window functions for Follow Mode (etc.). Message-ID: <20151111161914.GB5669@acm.fritz.box> References: <20151105192905.GA7986@acm.fritz.box> <20151107182420.GA1774@acm.fritz.box> <871tc18oai.fsf@mail.linkov.net> <20151108002955.GC1774@acm.fritz.box> <8737wgou4z.fsf@mail.linkov.net> <20151109154124.GC2284@acm.fritz.box> <87611a8x96.fsf@mail.linkov.net> <20151110110823.GB2626@acm.fritz.box> <876119s7fu.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <876119s7fu.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) Hello, Juri. On Wed, Nov 11, 2015 at 02:12:17AM +0200, Juri Linkov wrote: > > Can I ask you here to look at the initial patch in the archive for bug > > #17453 (see below)? > Thanks, I see. > > I posted the essence of the framework, as it now is, in a (cut down) > > patch at the beginning of this thread. I have complete patches for both > > the framework and isearch.el available. Together, they are really too > > big to post on emacs-devel. > Could you put them on a branch then? I've created the branch scratch/follow in savannah, with both the new framework and the proposed changes to isearch.el. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 11 20:00:10 2015 Received: (at 17453) by debbugs.gnu.org; 12 Nov 2015 01:00:10 +0000 Received: from localhost ([127.0.0.1]:33746 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZwgFE-0005ld-S4 for submit@debbugs.gnu.org; Wed, 11 Nov 2015 20:00:09 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:55073 helo=homiemail-a39.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZwgF9-0005l9-FG for 17453@debbugs.gnu.org; Wed, 11 Nov 2015 20:00:04 -0500 Received: from homiemail-a39.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTP id D6951150074; Wed, 11 Nov 2015 17:00:00 -0800 (PST) Received: from localhost.linkov.net (m83-180-116-181.cust.tele2.ee [83.180.116.181]) (Authenticated sender: jurta@jurta.org) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTPA id C055C15006D; Wed, 11 Nov 2015 16:59:59 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: Framework extending window functions for Follow Mode (etc.). Organization: LINKOV.NET References: <20151105192905.GA7986@acm.fritz.box> <20151107182420.GA1774@acm.fritz.box> <871tc18oai.fsf@mail.linkov.net> <20151108002955.GC1774@acm.fritz.box> <8737wgou4z.fsf@mail.linkov.net> <20151109154124.GC2284@acm.fritz.box> <87611a8x96.fsf@mail.linkov.net> <20151110110823.GB2626@acm.fritz.box> <876119s7fu.fsf@mail.linkov.net> <20151111161914.GB5669@acm.fritz.box> Date: Thu, 12 Nov 2015 02:52:56 +0200 In-Reply-To: <20151111161914.GB5669@acm.fritz.box> (Alan Mackenzie's message of "Wed, 11 Nov 2015 16:19:14 +0000") Message-ID: <87egfwca3b.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> > I posted the essence of the framework, as it now is, in a (cut down) >> > patch at the beginning of this thread. I have complete patches for both >> > the framework and isearch.el available. Together, they are really too >> > big to post on emacs-devel. > >> Could you put them on a branch then? > > I've created the branch scratch/follow in savannah, with both the new > framework and the proposed changes to isearch.el. Thanks, I'm looking at your changes, and also Cc'ing Martin in the hope that Martin could review your window-related changes as well. PS: one immediate question - why do you need a new function isearch-call-message when at the top of this thread Stefan asked you to replace this code with (funcall (or isearch-message-function #'isearch-message) ,cqh ,ellip) and even to change isearch-message-function to default to isearch-message rather than to nil. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 12 03:23:07 2015 Received: (at 17453) by debbugs.gnu.org; 12 Nov 2015 08:23:07 +0000 Received: from localhost ([127.0.0.1]:33996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zwn9v-0007vP-Dq for submit@debbugs.gnu.org; Thu, 12 Nov 2015 03:23:07 -0500 Received: from mout.gmx.net ([212.227.17.21]:49430) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zwn9a-0007ud-FZ for 17453@debbugs.gnu.org; Thu, 12 Nov 2015 03:23:05 -0500 Received: from [192.168.1.101] ([213.162.68.2]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MEbYb-1aCVg034ob-00FiYo; Thu, 12 Nov 2015 09:22:41 +0100 Message-ID: <56444C48.5000609@gmx.at> Date: Thu, 12 Nov 2015 09:22:32 +0100 From: martin rudalics MIME-Version: 1.0 To: Juri Linkov , Alan Mackenzie Subject: Re: Framework extending window functions for Follow Mode (etc.). References: <20151105192905.GA7986@acm.fritz.box> <20151107182420.GA1774@acm.fritz.box> <871tc18oai.fsf@mail.linkov.net> <20151108002955.GC1774@acm.fritz.box> <8737wgou4z.fsf@mail.linkov.net> <20151109154124.GC2284@acm.fritz.box> <87611a8x96.fsf@mail.linkov.net> <20151110110823.GB2626@acm.fritz.box> <876119s7fu.fsf@mail.linkov.net> <20151111161914.GB5669@acm.fritz.box> <87egfwca3b.fsf@mail.linkov.net> In-Reply-To: <87egfwca3b.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:doVD2pCIaDPMQgU506exrY58KIol7HlTXYMTJw5Vr3D7TbBXB9P U7ixuUiZVBBLtglQd4mPQJwIrU139i4AG3ADXBvYUnGn9RV2PXjAemm4AK2OpOzF5xxfOl8 T5QB4DzsPImEPiro+zzZEoeEehBdBOonTyd2idcqOf4MQrLY8NgfNZtky6HM6iVk/LBIHuO XpZ+3LvHddE/9Ixv/FvOA== X-UI-Out-Filterresults: notjunk:1;V01:K0:/SW5Ow3Datc=:KkOB/lOuE4dukgZQTMWfYR HodzXY0tcL9cdKpyukEdx9H/tX1eK60CgrPKUNM9jSG0LPZzvm+lC8ivHPRJL7OVqSbKo7KiE YRsfl9Eh17Al4m/wNkddJpqmzyLA6Jeaoyc775Oza4eF2BwaqWrMYT6/40Y7H1amyKHKwwghv Ig9Gk4nC9zaiYAZTdxa4vS4BT4WKlIoiUI/QvOBX/lQtwge8vN8rQ6ZckzuPV+sHwGkMzBmwP L1KI5Lck3NTz5WpHjgKxOpd6FUTdeRMo3Me6Gc1qpgBDvISGK52iYcjlqsw34Z+x+Z637UcZx 17KZecH08dtDTUBLoECE45HKcl8iG1amby2kUehIcxrQ5h5qBDjRCqqSN47DZYgoKebeqLvhu OvPhbwJQNOLZrVA4oh+37ariT5CRtn4iOT+wNr/yHSd2eIEQhy/c1zuXdCWxcGDsRSiuvaSLR 1MqgbnsHAo0dOgo2XMe24wy6N+5RPef6bBBEjJeZIFXRf6QWCUmILc/WES9xPv9dLQNv3Wi11 Kc5b0hJL6aisYmuY3ykgQHYjB4YpeXA6LUovGxf31RcT7HBJlnjnqp6S0ptOivEuRrmXNaBvr rbcMEwwrAA4alPEtUk/3gFxeOu2D2Fm43ybGY6rwnEYI/YQODyhSxuHSESqLzl1JtPOIBoOvM 79YUh1JdtP4BRNWCi7TvSa7IHrz02JrU+s9wq46XqupVlGKpv6QTCCAO13evlY/ovcDjhWmdL LpkWUyWGuzc0EiYpe60lmCKY02yDP4vr9mHVBiW07QKOLLagEM9q78DPxphFmsZEqUIuefqq5 AJw0QoTxcx2lVlQUT0z8uIbh12dmw== X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Thanks, I'm looking at your changes, and also Cc'ing Martin in the hope > that Martin could review your window-related changes as well. Glimpsing on the window-related changes I think I have already said everything in this thread. Usurpating the term "group" in the sense that all windows belonging to a group have to show the same buffer seems overly restrictive but I don't want to continue the earlier discussion. [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.2 listed in zen.spamhaus.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.21 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record X-Debbugs-Envelope-To: 17453 Cc: 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Thanks, I'm looking at your changes, and also Cc'ing Martin in the hope > that Martin could review your window-related changes as well. Glimpsing on the window-related changes I think I have already said everything in this thread. Usurpating the term "group" in the sense that all windows belonging to a group have to show the same buffer seems overly restrictive but I don't want to continue the earlier discussion. [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.21 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.2 listed in zen.spamhaus.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record > Thanks, I'm looking at your changes, and also Cc'ing Martin in the hope > that Martin could review your window-related changes as well. Glimpsing on the window-related changes I think I have already said everything in this thread. Usurpating the term "group" in the sense that all windows belonging to a group have to show the same buffer seems overly restrictive but I don't want to continue the earlier discussion. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 12 15:16:27 2015 Received: (at 17453) by debbugs.gnu.org; 12 Nov 2015 20:16:27 +0000 Received: from localhost ([127.0.0.1]:35110 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZwyIE-0007nr-Ef for submit@debbugs.gnu.org; Thu, 12 Nov 2015 15:16:26 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:39491 helo=homiemail-a76.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZwyHt-0007nQ-O6 for 17453@debbugs.gnu.org; Thu, 12 Nov 2015 15:16:24 -0500 Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id BFC10458084; Thu, 12 Nov 2015 12:16:03 -0800 (PST) Received: from localhost.linkov.net (m83-191-160-148.cust.tele2.ee [83.191.160.148]) (Authenticated sender: jurta@jurta.org) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 9BAD7458081; Thu, 12 Nov 2015 12:16:02 -0800 (PST) From: Juri Linkov To: martin rudalics Subject: Re: Framework extending window functions for Follow Mode (etc.). Organization: LINKOV.NET References: <20151105192905.GA7986@acm.fritz.box> <20151107182420.GA1774@acm.fritz.box> <871tc18oai.fsf@mail.linkov.net> <20151108002955.GC1774@acm.fritz.box> <8737wgou4z.fsf@mail.linkov.net> <20151109154124.GC2284@acm.fritz.box> <87611a8x96.fsf@mail.linkov.net> <20151110110823.GB2626@acm.fritz.box> <876119s7fu.fsf@mail.linkov.net> <20151111161914.GB5669@acm.fritz.box> <87egfwca3b.fsf@mail.linkov.net> <56444C48.5000609@gmx.at> Date: Thu, 12 Nov 2015 22:14:22 +0200 In-Reply-To: <56444C48.5000609@gmx.at> (martin rudalics's message of "Thu, 12 Nov 2015 09:22:32 +0100") Message-ID: <8737wbx9ep.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: Alan Mackenzie , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> Thanks, I'm looking at your changes, and also Cc'ing Martin in the hope >> that Martin could review your window-related changes as well. > > Glimpsing on the window-related changes I think I have already said > everything in this thread. Usurpating the term "group" in the sense > that all windows belonging to a group have to show the same buffer seems > overly restrictive but I don't want to continue the earlier discussion. I agree that the cleanest way to add a new feature is not to change window primitives, but to add it on the top of existing window primitives by defining a new functional layer with a set of functions having a common name prefix either 'window-group-' or 'windows-' (used by follow.el in some places). Here are existing primitives and two variants of new functions: (window-start &optional WINDOW) (windows-start &optional WINDOW) (window-group-start &optional WINDOW) (set-window-start WINDOW POS &optional NOFORCE) (set-windows-start WINDOW POS &optional NOFORCE) (set-window-group-start WINDOW POS &optional NOFORCE) (move-to-window-line COUNT) (move-to-windows-line COUNT) (move-to-window-group-line COUNT) (pos-visible-in-window-p &optional POS WINDOW PARTIALLY) (pos-visible-in-windows-p &optional POS WINDOW PARTIALLY) (pos-visible-in-window-group-p &optional POS WINDOW PARTIALLY) These new functions could be defined in a new core package with a name like window-group.el or windows.el, or maybe added to the end of window.el, and have no follow-specific code. Then there is no need in a set of functions like window-start-group-function, because one function should be enough for a package like follow.el to declare an active group of windows via follow-all-followers, or packages other than follow.el using window parameters. Then window-group/windows functions should take care about all aspects of handling multiple windows. So e.g. new function follow-window-start will be window-group-start taking only follow-all-followers from follow.el, etc. This means that while adapting other packages to multi-window configurations, instead of adding the 't' arg to core primitives, we need to add 's' (window -> windows) or '-group' to the names of the existing function calls. The key point is not touching core primitives until we'll be able to implement a proper display abstraction for window groups such as proposed a while ago under the name "framelettes". This comment in follow.el also gives a hint in this direction: ;; Almost like the real thing, except when the cursor ends up outside ;; the top or bottom... In our case however, we end up outside the ;; window and hence we are recentered. Should we let `recenter' handle ;; the point position we would never leave the selected window. To do ;; it ourselves we would need to do our own redisplay, which is easier ;; said than done. (Why didn't I do a real display abstraction from ;; the beginning?) From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 12 17:13:31 2015 Received: (at 17453) by debbugs.gnu.org; 12 Nov 2015 22:13:31 +0000 Received: from localhost ([127.0.0.1]:35208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zx07W-0002Fp-TV for submit@debbugs.gnu.org; Thu, 12 Nov 2015 17:13:31 -0500 Received: from mail.muc.de ([193.149.48.3]:65143) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zx07U-0002Fe-Fh for 17453@debbugs.gnu.org; Thu, 12 Nov 2015 17:13:29 -0500 Received: (qmail 80722 invoked by uid 3782); 12 Nov 2015 22:13:27 -0000 Received: from acm.muc.de (p5B14648C.dip0.t-ipconnect.de [91.20.100.140]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 12 Nov 2015 23:13:25 +0100 Received: (qmail 7163 invoked by uid 1000); 12 Nov 2015 22:15:24 -0000 Date: Thu, 12 Nov 2015 22:15:24 +0000 To: Juri Linkov Subject: Re: Framework extending window functions for Follow Mode (etc.). Message-ID: <20151112221524.GH3120@acm.fritz.box> References: <20151107182420.GA1774@acm.fritz.box> <871tc18oai.fsf@mail.linkov.net> <20151108002955.GC1774@acm.fritz.box> <8737wgou4z.fsf@mail.linkov.net> <20151109154124.GC2284@acm.fritz.box> <87611a8x96.fsf@mail.linkov.net> <20151110110823.GB2626@acm.fritz.box> <876119s7fu.fsf@mail.linkov.net> <20151111161914.GB5669@acm.fritz.box> <87egfwca3b.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87egfwca3b.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.4 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.4 (/) Hello, Juri. On Thu, Nov 12, 2015 at 02:52:56AM +0200, Juri Linkov wrote: > >> > I posted the essence of the framework, as it now is, in a (cut down) > >> > patch at the beginning of this thread. I have complete patches for both > >> > the framework and isearch.el available. Together, they are really too > >> > big to post on emacs-devel. > >> Could you put them on a branch then? > > I've created the branch scratch/follow in savannah, with both the new > > framework and the proposed changes to isearch.el. > Thanks, I'm looking at your changes, and also Cc'ing Martin in the hope > that Martin could review your window-related changes as well. Thanks. > PS: one immediate question - why do you need a new function isearch-call-message > when at the top of this thread Stefan asked you to replace this code with > (funcall (or isearch-message-function #'isearch-message) ,cqh ,ellip) > and even to change isearch-message-function to default to isearch-message > rather than to nil. isearch-call-message is actually a macro. It's exists because it's invoked several times from the rest of the code, and is cleaner this way. Stefan's request just slipped my memory. It is a relatively minor stylistic thing, of little consequence. At the time he requested it, he had lots of far more important criticisms to make. But I could change it now, no problem. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 17 17:54:04 2015 Received: (at 17453) by debbugs.gnu.org; 17 Nov 2015 22:54:04 +0000 Received: from localhost ([127.0.0.1]:42104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zyp8W-0003Bt-7G for submit@debbugs.gnu.org; Tue, 17 Nov 2015 17:54:04 -0500 Received: from mail.muc.de ([193.149.48.3]:40956) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zyp8U-0003BU-6D for 17453@debbugs.gnu.org; Tue, 17 Nov 2015 17:54:03 -0500 Received: (qmail 29849 invoked by uid 3782); 17 Nov 2015 22:54:00 -0000 Received: from acm.muc.de (p579E91A5.dip0.t-ipconnect.de [87.158.145.165]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 17 Nov 2015 23:53:59 +0100 Received: (qmail 6583 invoked by uid 1000); 17 Nov 2015 22:55:58 -0000 Date: Tue, 17 Nov 2015 22:55:58 +0000 To: Juri Linkov Subject: Re: Framework extending window functions for Follow Mode (etc.). Message-ID: <20151117225558.GC5054@acm.fritz.box> References: <20151108002955.GC1774@acm.fritz.box> <8737wgou4z.fsf@mail.linkov.net> <20151109154124.GC2284@acm.fritz.box> <87611a8x96.fsf@mail.linkov.net> <20151110110823.GB2626@acm.fritz.box> <876119s7fu.fsf@mail.linkov.net> <20151111161914.GB5669@acm.fritz.box> <87egfwca3b.fsf@mail.linkov.net> <56444C48.5000609@gmx.at> <8737wbx9ep.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8737wbx9ep.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Hello, Juri. On Thu, Nov 12, 2015 at 10:14:22PM +0200, Juri Linkov wrote: > >> Thanks, I'm looking at your changes, and also Cc'ing Martin in the hope > >> that Martin could review your window-related changes as well. > > Glimpsing on the window-related changes I think I have already said > > everything in this thread. Usurpating the term "group" in the sense > > that all windows belonging to a group have to show the same buffer seems > > overly restrictive but I don't want to continue the earlier discussion. > I agree that the cleanest way to add a new feature is not to change window > primitives, but to add it on the top of existing window primitives > by defining a new functional layer with a set of functions having a common > name prefix either 'window-group-' or 'windows-' (used by follow.el in some > places). I am coming around to the idea that the new functions are a better way of implementing this than adding an extra optional parameter to the primitives. The reason is, I have a vision that some time in the medium future, the Follow Mode functionality will come to be implemented directly in the redisplay engine. If we add the extra parameter, it will then be redundant and stick out like a sore thumb. But with functions like `window-group-start', these functions could quietly merge with `window-start', etc., as soon as the display engine stuff is working. I have already implemented (though not committed) the extra functional layer. The names I used were `window*-start', ...., `move-to-window*-line'. Thinking about Anders's comment today that the "*" could easily get lost, .... > Here are existing primitives and two variants of new functions: > (window-start &optional WINDOW) > (windows-start &optional WINDOW) > (window-group-start &optional WINDOW) ...., I now think the best name would be the last of these three, window-group-start. It is not too long, and the phrase "window_group" fits in with all the primitives apart from `recenter'. So we'd need some different naming ideas, perhaps "recenter-group" or "group-recenter". > These new functions could be defined in a new core package with a name like > window-group.el or windows.el, or maybe added to the end of window.el, > and have no follow-specific code. I put them into window.el. It seems like a good place. > Then there is no need in a set of functions like window-start-group-function, > because one function should be enough for a package like follow.el > to declare an active group of windows via follow-all-followers, > or packages other than follow.el using window parameters. > Then window-group/windows functions should take care about all > aspects of handling multiple windows. We don't want Follow Mode to become too tightly coupled with "its users". > So e.g. new function follow-window-start will be window-group-start > taking only follow-all-followers from follow.el, etc. > This means that while adapting other packages to multi-window configurations, > instead of adding the 't' arg to core primitives, we need to add 's' (window -> windows) > or '-group' to the names of the existing function calls. I say the '-group' variant. > The key point is not touching core primitives until we'll be able to > implement a proper display abstraction for window groups such as proposed > a while ago under the name "framelettes". This comment in follow.el also > gives a hint in this direction: > ;; Almost like the real thing, except when the cursor ends up outside > ;; the top or bottom... In our case however, we end up outside the > ;; window and hence we are recentered. Should we let `recenter' handle > ;; the point position we would never leave the selected window. To do > ;; it ourselves we would need to do our own redisplay, which is easier > ;; said than done. (Why didn't I do a real display abstraction from > ;; the beginning?) Yes. By the way, have you had the chance to look at the changes I made to isearch.el in the scratch/follow branch? -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 17 20:23:04 2015 Received: (at 17453) by debbugs.gnu.org; 18 Nov 2015 01:23:04 +0000 Received: from localhost ([127.0.0.1]:42160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyrSh-0007c1-Nn for submit@debbugs.gnu.org; Tue, 17 Nov 2015 20:23:03 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:39930 helo=homiemail-a20.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyrSN-0007b9-Uh for 17453@debbugs.gnu.org; Tue, 17 Nov 2015 20:23:02 -0500 Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 9FA477EC072; Tue, 17 Nov 2015 17:22:42 -0800 (PST) Received: from localhost.linkov.net (m91-131-172-22.cust.tele2.ee [91.131.172.22]) (Authenticated sender: jurta@jurta.org) by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 89AB37EC064; Tue, 17 Nov 2015 17:22:41 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: Framework extending window functions for Follow Mode (etc.). Organization: LINKOV.NET References: <20151108002955.GC1774@acm.fritz.box> <8737wgou4z.fsf@mail.linkov.net> <20151109154124.GC2284@acm.fritz.box> <87611a8x96.fsf@mail.linkov.net> <20151110110823.GB2626@acm.fritz.box> <876119s7fu.fsf@mail.linkov.net> <20151111161914.GB5669@acm.fritz.box> <87egfwca3b.fsf@mail.linkov.net> <56444C48.5000609@gmx.at> <8737wbx9ep.fsf@mail.linkov.net> <20151117225558.GC5054@acm.fritz.box> Date: Wed, 18 Nov 2015 02:38:49 +0200 In-Reply-To: <20151117225558.GC5054@acm.fritz.box> (Alan Mackenzie's message of "Tue, 17 Nov 2015 22:55:58 +0000") Message-ID: <878u5w3zf2.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > ...., I now think the best name would be the last of these three, > window-group-start. It is not too long, and the phrase "window_group" > fits in with all the primitives apart from `recenter'. So we'd need some > different naming ideas, perhaps "recenter-group" or "group-recenter". For consistency with other related names it could have the same prefix, e.g. "window-group-recenter". > By the way, have you had the chance to look at the changes I made to > isearch.el in the scratch/follow branch? One thing in the isearch-related part of your patch that I'm not excited about is the macro isearch-call-message. With Stefan's request there is no need in it since it becomes one-liner: (funcall isearch-message-function). Another thing that disturbs me is moving lazy-highlighting checks to a new function isearch-lazy-highlight-maybe-new-loop. What do you think about moving only window-checking into new function i.e. only checks for window-start/window-end/etc that need (sit-for 0) and leaving other checks in isearch-lazy-highlight-new-loop? Would this help to avoid new problems such as un-highlighting postponed until the timer fires? From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 18 12:56:20 2015 Received: (at 17453) by debbugs.gnu.org; 18 Nov 2015 17:56:20 +0000 Received: from localhost ([127.0.0.1]:43620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz6xv-00075q-VI for submit@debbugs.gnu.org; Wed, 18 Nov 2015 12:56:20 -0500 Received: from mail.muc.de ([193.149.48.3]:55500) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz6xt-00075U-4X for 17453@debbugs.gnu.org; Wed, 18 Nov 2015 12:56:18 -0500 Received: (qmail 21715 invoked by uid 3782); 18 Nov 2015 17:56:15 -0000 Received: from acm.muc.de (p579E9E85.dip0.t-ipconnect.de [87.158.158.133]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 18 Nov 2015 18:56:15 +0100 Received: (qmail 2107 invoked by uid 1000); 18 Nov 2015 17:58:14 -0000 Date: Wed, 18 Nov 2015 17:58:14 +0000 To: Juri Linkov Subject: Re: Framework extending window functions for Follow Mode (etc.). Message-ID: <20151118175814.GA1690@acm.fritz.box> References: <20151109154124.GC2284@acm.fritz.box> <87611a8x96.fsf@mail.linkov.net> <20151110110823.GB2626@acm.fritz.box> <876119s7fu.fsf@mail.linkov.net> <20151111161914.GB5669@acm.fritz.box> <87egfwca3b.fsf@mail.linkov.net> <56444C48.5000609@gmx.at> <8737wbx9ep.fsf@mail.linkov.net> <20151117225558.GC5054@acm.fritz.box> <878u5w3zf2.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878u5w3zf2.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Hello, Juri. On Wed, Nov 18, 2015 at 02:38:49AM +0200, Juri Linkov wrote: > > ...., I now think the best name would be the last of these three, > > window-group-start. It is not too long, and the phrase "window_group" > > fits in with all the primitives apart from `recenter'. So we'd need some > > different naming ideas, perhaps "recenter-group" or "group-recenter". > For consistency with other related names it could have the same prefix, e.g. > "window-group-recenter". Or even "recenter-window-group", since "window-group" isn't strictly a prefix in a lot of the other cases anyway. > > By the way, have you had the chance to look at the changes I made to > > isearch.el in the scratch/follow branch? > One thing in the isearch-related part of your patch that I'm not excited about > is the macro isearch-call-message. With Stefan's request there is no need in it > since it becomes one-liner: (funcall isearch-message-function). A minor thing, which I will amend this evening. > Another thing that disturbs me is moving lazy-highlighting checks > to a new function isearch-lazy-highlight-maybe-new-loop. What disturbs you about this change in particular? > What do you think about moving only window-checking into new function > i.e. only checks for window-start/window-end/etc that need (sit-for 0) > and leaving other checks in isearch-lazy-highlight-new-loop? Actually, I think that "(sit-for 0)" isn't needed - I left it in to deal with isearch-lazy-highlight-initial-delay being set to 0, thinking that Follow Mode's post-command-hook might "not have had time" to run. But surely post-command-hook will be called before checking timers. I'll need to look at the source code (probably keyboard.c) to be absolutely sure of this. I don't think splitting the checks between isearch-lazy-highlight-new-loop (in the command loop) and a function triggered by a timer is a good idea. I tried it out, and it kind of jars when the lazy highlighting sometimes stays 0.25s, sometimes goes instantly. How about maybe ... How about maybe putting the test for new highlighting in Isearch's post-command-hook (and using the APPEND argument of `add-hook' to make sure Isearch's post-hook-function comes after Follow Modes's)? That way, all the lazy h. would be removed immediately after the command, as at present. > Would this help to avoid new problems such as un-highlighting > postponed until the timer fires? Is this actually a problem? I played with Emacs a little with that un-highlighting strategy, and didn't find it any more disturbing than the 0.25s gap between old highlighting going and new highlighting arriving. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 18 16:26:45 2015 Received: (at 17453) by debbugs.gnu.org; 18 Nov 2015 21:26:46 +0000 Received: from localhost ([127.0.0.1]:43819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzAFZ-0007ow-E9 for submit@debbugs.gnu.org; Wed, 18 Nov 2015 16:26:45 -0500 Received: from mail.muc.de ([193.149.48.3]:46626) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzAFE-0007oT-Fa for 17453@debbugs.gnu.org; Wed, 18 Nov 2015 16:26:43 -0500 Received: (qmail 67586 invoked by uid 3782); 18 Nov 2015 21:26:23 -0000 Received: from acm.muc.de (p579E9E85.dip0.t-ipconnect.de [87.158.158.133]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 18 Nov 2015 22:26:22 +0100 Received: (qmail 18465 invoked by uid 1000); 18 Nov 2015 21:28:22 -0000 Date: Wed, 18 Nov 2015 21:28:22 +0000 To: Juri Linkov Subject: Re: Framework extending window functions for Follow Mode (etc.). Message-ID: <20151118212822.GA18461@acm.fritz.box> References: <87611a8x96.fsf@mail.linkov.net> <20151110110823.GB2626@acm.fritz.box> <876119s7fu.fsf@mail.linkov.net> <20151111161914.GB5669@acm.fritz.box> <87egfwca3b.fsf@mail.linkov.net> <56444C48.5000609@gmx.at> <8737wbx9ep.fsf@mail.linkov.net> <20151117225558.GC5054@acm.fritz.box> <878u5w3zf2.fsf@mail.linkov.net> <20151118175814.GA1690@acm.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151118175814.GA1690@acm.fritz.box> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Hello again, Juri. On Wed, Nov 18, 2015 at 05:58:14PM +0000, Alan Mackenzie wrote: > > One thing in the isearch-related part of your patch that I'm not excited about > > is the macro isearch-call-message. With Stefan's request there is no need in it > > since it becomes one-liner: (funcall isearch-message-function). > A minor thing, which I will amend this evening. DONE. I have committed the patch to the scratch/follow branch of the repository. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 18 20:07:48 2015 Received: (at 17453) by debbugs.gnu.org; 19 Nov 2015 01:07:49 +0000 Received: from localhost ([127.0.0.1]:43896 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzDhU-00064G-Dw for submit@debbugs.gnu.org; Wed, 18 Nov 2015 20:07:48 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:45790 helo=homiemail-a76.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzDh9-00063I-T8 for 17453@debbugs.gnu.org; Wed, 18 Nov 2015 20:07:46 -0500 Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 8232745807C; Wed, 18 Nov 2015 17:07:27 -0800 (PST) Received: from localhost.linkov.net (m91-131-172-22.cust.tele2.ee [91.131.172.22]) (Authenticated sender: jurta@jurta.org) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 62D6F45807B; Wed, 18 Nov 2015 17:07:26 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: Framework extending window functions for Follow Mode (etc.). Organization: LINKOV.NET References: <20151109154124.GC2284@acm.fritz.box> <87611a8x96.fsf@mail.linkov.net> <20151110110823.GB2626@acm.fritz.box> <876119s7fu.fsf@mail.linkov.net> <20151111161914.GB5669@acm.fritz.box> <87egfwca3b.fsf@mail.linkov.net> <56444C48.5000609@gmx.at> <8737wbx9ep.fsf@mail.linkov.net> <20151117225558.GC5054@acm.fritz.box> <878u5w3zf2.fsf@mail.linkov.net> <20151118175814.GA1690@acm.fritz.box> Date: Thu, 19 Nov 2015 02:45:43 +0200 In-Reply-To: <20151118175814.GA1690@acm.fritz.box> (Alan Mackenzie's message of "Wed, 18 Nov 2015 17:58:14 +0000") Message-ID: <87egfmkea0.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> For consistency with other related names it could have the same prefix, e.g. >> "window-group-recenter". > > Or even "recenter-window-group", since "window-group" isn't strictly a > prefix in a lot of the other cases anyway. Maybe "recenter-window-group" in the sense of "recenter a window in the window group" as opposed to "window-group-recenter" in the sense of "recenter the whole window group"? >> Another thing that disturbs me is moving lazy-highlighting checks >> to a new function isearch-lazy-highlight-maybe-new-loop. > > What disturbs you about this change in particular? The same consequences you mentioned earlier: various time periods of lazy-highlighting staying active. >> What do you think about moving only window-checking into new function >> i.e. only checks for window-start/window-end/etc that need (sit-for 0) >> and leaving other checks in isearch-lazy-highlight-new-loop? > > Actually, I think that "(sit-for 0)" isn't needed - I left it in to deal > with isearch-lazy-highlight-initial-delay being set to 0, thinking that > Follow Mode's post-command-hook might "not have had time" to run. But > surely post-command-hook will be called before checking timers. I'll > need to look at the source code (probably keyboard.c) to be absolutely > sure of this. > > I don't think splitting the checks between > isearch-lazy-highlight-new-loop (in the command loop) and a function > triggered by a timer is a good idea. I tried it out, and it kind of > jars when the lazy highlighting sometimes stays 0.25s, sometimes goes > instantly. How about maybe ... > > How about maybe putting the test for new highlighting in Isearch's > post-command-hook (and using the APPEND argument of `add-hook' to make > sure Isearch's post-hook-function comes after Follow Modes's)? That > way, all the lazy h. would be removed immediately after the command, as > at present. You could try to append a new follow+isearch specific hook to post-command-hook in follow.el, if this helps. >> Would this help to avoid new problems such as un-highlighting >> postponed until the timer fires? > > Is this actually a problem? I played with Emacs a little with that > un-highlighting strategy, and didn't find it any more disturbing than > the 0.25s gap between old highlighting going and new highlighting > arriving. We need to test the same in all modes that use lazy-highlighting too. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 25 14:31:00 2015 Received: (at 17453) by debbugs.gnu.org; 25 Nov 2015 19:31:00 +0000 Received: from localhost ([127.0.0.1]:53154 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1fmO-0008B2-3O for submit@debbugs.gnu.org; Wed, 25 Nov 2015 14:31:00 -0500 Received: from mail.muc.de ([193.149.48.3]:53406) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1fmL-0008At-Iw for 17453@debbugs.gnu.org; Wed, 25 Nov 2015 14:30:58 -0500 Received: (qmail 33610 invoked by uid 3782); 25 Nov 2015 19:30:56 -0000 Received: from acm.muc.de (p5B146B74.dip0.t-ipconnect.de [91.20.107.116]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 25 Nov 2015 20:30:55 +0100 Received: (qmail 23138 invoked by uid 1000); 25 Nov 2015 19:33:01 -0000 Date: Wed, 25 Nov 2015 19:33:01 +0000 To: Juri Linkov Subject: Re: Framework extending window functions for Follow Mode (etc.). Message-ID: <20151125193301.GI2007@acm.fritz.box> References: <20151110110823.GB2626@acm.fritz.box> <876119s7fu.fsf@mail.linkov.net> <20151111161914.GB5669@acm.fritz.box> <87egfwca3b.fsf@mail.linkov.net> <56444C48.5000609@gmx.at> <8737wbx9ep.fsf@mail.linkov.net> <20151117225558.GC5054@acm.fritz.box> <878u5w3zf2.fsf@mail.linkov.net> <20151118175814.GA1690@acm.fritz.box> <87egfmkea0.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87egfmkea0.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Hello, Juri It's been nearly a week since your last email. In that time, I tried one of the approaches (see below) that worked just fine.... except it wouldn't work with replace.el. I got discouraged by this, and moved onto other things for a while. Now I'm back. On Thu, Nov 19, 2015 at 02:45:43AM +0200, Juri Linkov wrote: > >> Another thing that disturbs me is moving lazy-highlighting checks > >> to a new function isearch-lazy-highlight-maybe-new-loop. > > What disturbs you about this change in particular? > The same consequences you mentioned earlier: various time periods > of lazy-highlighting staying active. OK. > >> What do you think about moving only window-checking into new function > >> i.e. only checks for window-start/window-end/etc that need (sit-for 0) > >> and leaving other checks in isearch-lazy-highlight-new-loop? > > Actually, I think that "(sit-for 0)" isn't needed - I left it in to deal > > with isearch-lazy-highlight-initial-delay being set to 0, thinking that > > Follow Mode's post-command-hook might "not have had time" to run. But > > surely post-command-hook will be called before checking timers. I'll > > need to look at the source code (probably keyboard.c) to be absolutely > > sure of this. The "(sit-for 0)" is absolutely not needed: post-command-hook is indeed always invoked before Emacs checks for timer expiry; I tried this out. > > I don't think splitting the checks between > > isearch-lazy-highlight-new-loop (in the command loop) and a function > > triggered by a timer is a good idea. I tried it out, and it kind of > > jars when the lazy highlighting sometimes stays 0.25s, sometimes goes > > instantly. How about maybe ... > > How about maybe putting the test for new highlighting in Isearch's > > post-command-hook (and using the APPEND argument of `add-hook' to make > > sure Isearch's post-hook-function comes after Follow Modes's)? That > > way, all the lazy h. would be removed immediately after the command, as > > at present. This is precisely what I tried. It works very well in Isearch. However, the problem is in replace.el (the replace functionality, not `occur'): `query-replace', instead of using the Command Loop like Isearch does, implements its own command loop. This seems suboptimal: it doesn't invoke post-command-hook (or pre-command-hook) until the entire replace session is over. This means the use of `query-replace' whilst Follow Mode is enabled is not going to work properly, without some radical change in replace.el. Probably the smallest change would be to invoke new hooks `pre-replace-command-hook' and `post-replace-command-hook' from `query-replace''s command loop. A more satisfying change would be to get rid of `perform-replace' and use Emacs's command loop the way Isearch does. This would probably not be all that difficult. Do you know if there's any special reason `query-replace' implements its own command loop? What do you think? [ .... ] > We need to test the same in all modes that use lazy-highlighting too. Yes. That's a problem, right now. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 26 18:20:41 2015 Received: (at 17453) by debbugs.gnu.org; 26 Nov 2015 23:20:41 +0000 Received: from localhost ([127.0.0.1]:54735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a25qC-00018U-Ut for submit@debbugs.gnu.org; Thu, 26 Nov 2015 18:20:41 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:60157 helo=homiemail-a11.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a25q7-00018I-O7 for 17453@debbugs.gnu.org; Thu, 26 Nov 2015 18:20:36 -0500 Received: from homiemail-a11.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a11.g.dreamhost.com (Postfix) with ESMTP id AFB856E06C; Thu, 26 Nov 2015 15:20:34 -0800 (PST) Received: from localhost.linkov.net (m212-53-115-218.cust.tele2.ee [212.53.115.218]) (Authenticated sender: jurta@jurta.org) by homiemail-a11.g.dreamhost.com (Postfix) with ESMTPA id 8E7F56E06A; Thu, 26 Nov 2015 15:20:33 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: Framework extending window functions for Follow Mode (etc.). Organization: LINKOV.NET References: <20151110110823.GB2626@acm.fritz.box> <876119s7fu.fsf@mail.linkov.net> <20151111161914.GB5669@acm.fritz.box> <87egfwca3b.fsf@mail.linkov.net> <56444C48.5000609@gmx.at> <8737wbx9ep.fsf@mail.linkov.net> <20151117225558.GC5054@acm.fritz.box> <878u5w3zf2.fsf@mail.linkov.net> <20151118175814.GA1690@acm.fritz.box> <87egfmkea0.fsf@mail.linkov.net> <20151125193301.GI2007@acm.fritz.box> Date: Fri, 27 Nov 2015 01:03:43 +0200 In-Reply-To: <20151125193301.GI2007@acm.fritz.box> (Alan Mackenzie's message of "Wed, 25 Nov 2015 19:33:01 +0000") Message-ID: <8737vs8isw.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > This means the use of `query-replace' whilst Follow Mode is enabled is > not going to work properly, without some radical change in replace.el. > > Probably the smallest change would be to invoke new hooks > `pre-replace-command-hook' and `post-replace-command-hook' from > `query-replace''s command loop. > > A more satisfying change would be to get rid of `perform-replace' and > use Emacs's command loop the way Isearch does. This would probably not > be all that difficult. Do you know if there's any special reason > `query-replace' implements its own command loop? The patch in bug#20430 awaits the possibility of helping to fix this problem. It adds a new hook replace-update-post-hook that is like its isearch counterpart hook isearch-update-post-hook is the right way to handle display updates like syncing follow windows, etc. Together with changing the order of calling isearch-update-post-hook and isearch-lazy-highlight-new-loop in isearch-update, adding follow-post-command-hook to isearch-update-post-hook, and adding follow-post-command-hook to replace-update-post-hook to handle follow-mode in query-replace will comprise the least radical change just before the next release. Do you see a shortcoming of this course of action? From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 30 15:35:26 2015 Received: (at 17453) by debbugs.gnu.org; 30 Nov 2015 20:35:26 +0000 Received: from localhost ([127.0.0.1]:33303 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3VAS-0004JX-Vv for submit@debbugs.gnu.org; Mon, 30 Nov 2015 15:35:25 -0500 Received: from mail.muc.de ([193.149.48.3]:56123) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3VAP-0004JL-C7 for 17453@debbugs.gnu.org; Mon, 30 Nov 2015 15:35:22 -0500 Received: (qmail 5731 invoked by uid 3782); 30 Nov 2015 20:35:19 -0000 Received: from acm.muc.de (p548A5058.dip0.t-ipconnect.de [84.138.80.88]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 30 Nov 2015 21:35:17 +0100 Received: (qmail 20934 invoked by uid 1000); 30 Nov 2015 20:37:23 -0000 Date: Mon, 30 Nov 2015 20:37:23 +0000 To: Juri Linkov Subject: Re: Framework extending window functions for Follow Mode (etc.). Message-ID: <20151130203723.GA24162@acm.fritz.box> References: <20151111161914.GB5669@acm.fritz.box> <87egfwca3b.fsf@mail.linkov.net> <56444C48.5000609@gmx.at> <8737wbx9ep.fsf@mail.linkov.net> <20151117225558.GC5054@acm.fritz.box> <878u5w3zf2.fsf@mail.linkov.net> <20151118175814.GA1690@acm.fritz.box> <87egfmkea0.fsf@mail.linkov.net> <20151125193301.GI2007@acm.fritz.box> <8737vs8isw.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8737vs8isw.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Juri. On Fri, Nov 27, 2015 at 01:03:43AM +0200, Juri Linkov wrote: > > This means the use of `query-replace' whilst Follow Mode is enabled is > > not going to work properly, without some radical change in replace.el. > > Probably the smallest change would be to invoke new hooks > > `pre-replace-command-hook' and `post-replace-command-hook' from > > `query-replace''s command loop. > > A more satisfying change would be to get rid of `perform-replace' and > > use Emacs's command loop the way Isearch does. This would probably not > > be all that difficult. Do you know if there's any special reason > > `query-replace' implements its own command loop? > The patch in bug#20430 awaits the possibility of helping to fix this > problem. It adds a new hook replace-update-post-hook that is like > its isearch counterpart hook isearch-update-post-hook is the right way > to handle display updates like syncing follow windows, etc. Does this patch exist, yet? It bothers me a little that we might be adding hook after hook into Emacs, each one for a single special purpose. Would it not perhaps be better to call `isearch-update-post-hook' also from `perform-replace', since that would be more economical with hooks; the meaning of the hook invocation would be "the same" in Isearch and `perform-replace' - "hook called after having moved to the next match". > Together with changing the order of calling isearch-update-post-hook > and isearch-lazy-highlight-new-loop in isearch-update, adding > follow-post-command-hook to isearch-update-post-hook, and adding > follow-post-command-hook to replace-update-post-hook to handle > follow-mode in query-replace will comprise the least radical change > just before the next release. This sounds like a good idea. Though, again, I think calling isearch-update-post-hook from `query-replace' would be better than implementing a new hook. > Do you see a shortcoming of this course of action? Only that it is working around the problems in replace.el rather than fixing them. But to fix them properly would mean a radical redesign of `perform-replace', or superseding it altogether, which is probably best postponed until 25.2 or later. I still think `post-command-hook' is the best hook for us to use - but it isn't called from `query-replace'. Would it still be possible to mark `isearch-update-post-hook' as "for internal use only", so that we could get rid of it later? -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 30 19:08:54 2015 Received: (at 17453) by debbugs.gnu.org; 1 Dec 2015 00:08:54 +0000 Received: from localhost ([127.0.0.1]:33411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3YV4-0002ek-30 for submit@debbugs.gnu.org; Mon, 30 Nov 2015 19:08:54 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:57963 helo=homiemail-a11.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3YUj-0002eJ-W4 for 17453@debbugs.gnu.org; Mon, 30 Nov 2015 19:08:53 -0500 Received: from homiemail-a11.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a11.g.dreamhost.com (Postfix) with ESMTP id 37CAC6E06C; Mon, 30 Nov 2015 16:08:33 -0800 (PST) Received: from localhost.linkov.net (m213-102-86-182.cust.tele2.ee [213.102.86.182]) (Authenticated sender: jurta@jurta.org) by homiemail-a11.g.dreamhost.com (Postfix) with ESMTPA id 13F916E06A; Mon, 30 Nov 2015 16:08:31 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: Framework extending window functions for Follow Mode (etc.). Organization: LINKOV.NET References: <20151111161914.GB5669@acm.fritz.box> <87egfwca3b.fsf@mail.linkov.net> <56444C48.5000609@gmx.at> <8737wbx9ep.fsf@mail.linkov.net> <20151117225558.GC5054@acm.fritz.box> <878u5w3zf2.fsf@mail.linkov.net> <20151118175814.GA1690@acm.fritz.box> <87egfmkea0.fsf@mail.linkov.net> <20151125193301.GI2007@acm.fritz.box> <8737vs8isw.fsf@mail.linkov.net> <20151130203723.GA24162@acm.fritz.box> Date: Tue, 01 Dec 2015 02:07:31 +0200 In-Reply-To: <20151130203723.GA24162@acm.fritz.box> (Alan Mackenzie's message of "Mon, 30 Nov 2015 20:37:23 +0000") Message-ID: <874mg33ubg.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> The patch in bug#20430 awaits the possibility of helping to fix this >> problem. It adds a new hook replace-update-post-hook that is like >> its isearch counterpart hook isearch-update-post-hook is the right way >> to handle display updates like syncing follow windows, etc. > > Does this patch exist, yet? Yes, you can find the patch in http://debbugs.gnu.org/20430#8 > It bothers me a little that we might be adding hook after hook into > Emacs, each one for a single special purpose. Fortunately, a new hook is not for a single special purpose - it's a general type of hook, requested for different user needs. > Would it not perhaps be better to call `isearch-update-post-hook' also > from `perform-replace', since that would be more economical with hooks; > the meaning of the hook invocation would be "the same" in Isearch and > `perform-replace' - "hook called after having moved to the next match". Logically, it makes sense to reuse isearch hooks in query-replace since query-replace searches for matches like isearch does, but practically users might have such customizations in .emacs that would break query-replace in unpredictable ways. This is why a separate query-replace hook would be much safer. I see no problem for follow-mode to add follow-post-command-hook to both hooks. >> Together with changing the order of calling isearch-update-post-hook >> and isearch-lazy-highlight-new-loop in isearch-update, adding >> follow-post-command-hook to isearch-update-post-hook, and adding >> follow-post-command-hook to replace-update-post-hook to handle >> follow-mode in query-replace will comprise the least radical change >> just before the next release. > > This sounds like a good idea. Though, again, I think calling > isearch-update-post-hook from `query-replace' would be better than > implementing a new hook. Adding a new hook is just a one-liner, but we have to find the right place in perform-replace to call it. I think replace-update-pre-hook should be called before (read-event), and replace-update-post-hook after (read-event). I'm not yet sure which one is needed for follow-mode to sync windows? > Would it still be possible to mark `isearch-update-post-hook' as "for > internal use only", so that we could get rid of it later? isearch-update-post-hook is a first-class hook added 5 years ago, so there is no need to remove it. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 05 11:38:46 2015 Received: (at 17453) by debbugs.gnu.org; 5 Dec 2015 16:38:46 +0000 Received: from localhost ([127.0.0.1]:40016 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a5FrB-0007Ta-0u for submit@debbugs.gnu.org; Sat, 05 Dec 2015 11:38:46 -0500 Received: from mail.muc.de ([193.149.48.3]:34188) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a5Fqq-0007T4-9m for 17453@debbugs.gnu.org; Sat, 05 Dec 2015 11:38:43 -0500 Received: (qmail 62189 invoked by uid 3782); 5 Dec 2015 16:38:23 -0000 Received: from acm.muc.de (p548A4450.dip0.t-ipconnect.de [84.138.68.80]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 05 Dec 2015 17:38:22 +0100 Received: (qmail 3831 invoked by uid 1000); 5 Dec 2015 16:40:32 -0000 Date: Sat, 5 Dec 2015 16:40:32 +0000 To: Juri Linkov Subject: Re: Framework extending window functions for Follow Mode (etc.). Message-ID: <20151205164032.GD2698@acm.fritz.box> References: <56444C48.5000609@gmx.at> <8737wbx9ep.fsf@mail.linkov.net> <20151117225558.GC5054@acm.fritz.box> <878u5w3zf2.fsf@mail.linkov.net> <20151118175814.GA1690@acm.fritz.box> <87egfmkea0.fsf@mail.linkov.net> <20151125193301.GI2007@acm.fritz.box> <8737vs8isw.fsf@mail.linkov.net> <20151130203723.GA24162@acm.fritz.box> <874mg33ubg.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874mg33ubg.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Juri. On Tue, Dec 01, 2015 at 02:07:31AM +0200, Juri Linkov wrote: > >> The patch in bug#20430 awaits the possibility of helping to fix this > >> problem. It adds a new hook replace-update-post-hook that is like > >> its isearch counterpart hook isearch-update-post-hook is the right way > >> to handle display updates like syncing follow windows, etc. > > Does this patch exist, yet? > Yes, you can find the patch in http://debbugs.gnu.org/20430#8 OK, I've got it. > > It bothers me a little that we might be adding hook after hook into > > Emacs, each one for a single special purpose. > Fortunately, a new hook is not for a single special purpose - > it's a general type of hook, requested for different user needs. I'll stop arguing the philosophy right now (and take it up again a bit lower down). ;-) > > Would it not perhaps be better to call `isearch-update-post-hook' also > > from `perform-replace', since that would be more economical with hooks; > > the meaning of the hook invocation would be "the same" in Isearch and > > `perform-replace' - "hook called after having moved to the next match". > Logically, it makes sense to reuse isearch hooks in query-replace > since query-replace searches for matches like isearch does, but > practically users might have such customizations in .emacs that > would break query-replace in unpredictable ways. This is why > a separate query-replace hook would be much safer. > I see no problem for follow-mode to add follow-post-command-hook > to both hooks. Because this ties Follow Mode to implementation details of isearch.el, replace.el, and ispell.el. It is plain ugly for Follow Mode to have to add-hook an obscure hook for every package that attempts lazy highlighting. (add-hook 'post-command-hook follow-post-command-hook nil t) should be the only pertinent 'add-hook necessary in follow-mode (and it would be if isearch.el were the only library to adpat for - I had it working at one point). It's not, because replace.el and ispell.el both attempt to implement their own command loops rather than using Emacs's standard one. These design decisions were Bad. > >> Together with changing the order of calling isearch-update-post-hook > >> and isearch-lazy-highlight-new-loop in isearch-update, adding > >> follow-post-command-hook to isearch-update-post-hook, and adding > >> follow-post-command-hook to replace-update-post-hook to handle > >> follow-mode in query-replace will comprise the least radical change > >> just before the next release. > > This sounds like a good idea. Though, again, I think calling > > isearch-update-post-hook from `query-replace' would be better than > > implementing a new hook. > Adding a new hook is just a one-liner, but we have to find the right place > in perform-replace to call it. I think replace-update-pre-hook should be > called before (read-event), and replace-update-post-hook after (read-event). > I'm not yet sure which one is needed for follow-mode to sync windows? At the moment there is only replace-update-post-hook. It is called after point has been moved, but before i-l-highlight-new-loop is called. I had to move it slightly from where your patch had put it. > > Would it still be possible to mark `isearch-update-post-hook' as "for > > internal use only", so that we could get rid of it later? > isearch-update-post-hook is a first-class hook added 5 years ago, > so there is no need to remove it. Sorry, I made a typo there. I really meant replace-update-post-hook. Can we somehow keep this "internal use only", so that we are not bound somehow to keep supporting it should the `query-replace' command loop be reformulated (as believe it should, ASAP)? The same applies to ispell-update-post-hook, which I've been forced to introduce into ispell.el for the same reason. ######################################################################### Anyhow, here's a status update with where I am on making isearch.el and follow.el work together: (i) Yesterday I rebased the scratch/follow branch on the emacs-25 branch. (ii) I haven't yet replaced the GROUP parameter in the windows primitives with (e.g.) `window-group-start'. (iii) isearch.el now appears to work properly. For this, I had to swap the order of invocation of isearch-update-post-hook and i-l-h-new-loop, like you said. I restored i-l-h-new-loop pretty much to the way it was prior to my experimentations. (iv) replace.el now appears to work properly. (v) ispell.el is more troublesome. See bug #22097. I have a problem with ispell putting its *Choices* window at the top of the left hand Follow Mode window. Because of FM's sorting algorithm, this causes the two windows to be logically swapped, leading to confusing results. I think the neatest solution would be to put *Choices* at the top of the rightmost window, preventing this. Here's a diff of my current state, based off of the rebased scratch/follow branch mentioned above in (i): diff --git a/.gitignore b/.gitignore index 34b0c02..5ef5a5c 100644 --- a/.gitignore +++ b/.gitignore @@ -261,6 +261,10 @@ ChangeLog [0-9]*.txt .dir-locals?.el /vc-dwim-log-* +*.diff + +.gitattributes +*.acm # Built by 'make install'. etc/emacs.tmpdesktop diff --git a/lisp/follow.el b/lisp/follow.el index 2cbf0f2..609b29f 100644 --- a/lisp/follow.el +++ b/lisp/follow.el @@ -423,6 +423,9 @@ follow-mode (add-hook 'post-command-hook 'follow-post-command-hook t) (add-hook 'window-size-change-functions 'follow-window-size-change t) (add-hook 'after-change-functions 'follow-after-change nil t) + (add-hook 'isearch-update-post-hook 'follow-post-command-hook nil t) + (add-hook 'replace-update-post-hook 'follow-post-command-hook nil t) + (add-hook 'ispell-update-post-hook 'follow-post-command-hook nil t) (setq window-start-group-function 'follow-window-start) (setq window-end-group-function 'follow-window-end) @@ -431,8 +434,7 @@ follow-mode (setq pos-visible-in-window-p-group-function 'follow-pos-visible-in-window-p) (setq selected-window-group-function 'follow-all-followers) - (setq move-to-window-line-group-function 'follow-move-to-window-line) - (setq sit*-for-function 'follow-sit-for)) + (setq move-to-window-line-group-function 'follow-move-to-window-line)) ;; Remove globally-installed hook functions only if there is no ;; other Follow mode buffer. @@ -445,7 +447,6 @@ follow-mode (remove-hook 'post-command-hook 'follow-post-command-hook) (remove-hook 'window-size-change-functions 'follow-window-size-change))) - (kill-local-variable 'sit*-for-function) (kill-local-variable 'move-to-window-line-group-function) (kill-local-variable 'selected-window-group-function) (kill-local-variable 'pos-visible-in-window-p-group-function) @@ -454,6 +455,9 @@ follow-mode (kill-local-variable 'window-end-group-function) (kill-local-variable 'window-start-group-function) + (remove-hook 'ispell-update-post-hook 'follow-post-command-hook t) + (remove-hook 'replace-update-post-hook 'follow-post-command-hook t) + (remove-hook 'isearch-update-post-hook 'follow-post-command-hook t) (remove-hook 'after-change-functions 'follow-after-change t) (remove-hook 'compilation-filter-hook 'follow-align-compilation-windows t))) diff --git a/lisp/isearch.el b/lisp/isearch.el index 12ded02..e43d860 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -1018,12 +1018,12 @@ isearch-update (setq ;; quit-flag nil not for isearch-mode isearch-adjusted nil isearch-yank-flag nil) - (when isearch-lazy-highlight - (isearch-lazy-highlight-new-loop)) ;; We must prevent the point moving to the end of composition when a ;; part of the composition has just been searched. (setq disable-point-adjustment t) - (run-hooks 'isearch-update-post-hook)) + (run-hooks 'isearch-update-post-hook) + (when isearch-lazy-highlight + (isearch-lazy-highlight-new-loop))) (defun isearch-done (&optional nopush edit) "Exit Isearch mode. @@ -3068,21 +3068,7 @@ 'isearch-lazy-highlight-cleanup "22.1") (defun isearch-lazy-highlight-new-loop (&optional beg end) - "Set an idle timer, which will trigger a new `lazy-highlight' loop. -BEG and END specify the bounds within which highlighting should -occur. This is called when `isearch-update' is invoked (which -can cause the search string to change or the window(s) to -scroll). It is also used by other Emacs features. Do not start -the loop when we are executing a keyboard macro." - (setq isearch-lazy-highlight-start-limit beg - isearch-lazy-highlight-end-limit end) - (when (null executing-kbd-macro) - (setq isearch-lazy-highlight-timer - (run-with-idle-timer lazy-highlight-initial-delay nil - 'isearch-lazy-highlight-maybe-new-loop)))) - -(defun isearch-lazy-highlight-maybe-new-loop () - "If needed cleanup any previous `lazy-highlight' loop and begin a new one. + "Cleanup any previous `lazy-highlight' loop and begin a new one. BEG and END specify the bounds within which highlighting should occur. This is called when `isearch-update' is invoked (which can cause the search string to change or the window to scroll). It is also used @@ -3118,6 +3104,8 @@ isearch-lazy-highlight-maybe-new-loop ;; It used to check for `(not isearch-error)' here, but actually ;; lazy-highlighting might find matches to highlight even when ;; `isearch-error' is non-nil. (Bug#9918) + (setq isearch-lazy-highlight-start-limit beg + isearch-lazy-highlight-end-limit end) (setq isearch-lazy-highlight-window (selected-window) isearch-lazy-highlight-window-group (selected-window-group) isearch-lazy-highlight-window-start (window-start nil t) @@ -3140,7 +3128,9 @@ isearch-lazy-highlight-maybe-new-loop isearch-lazy-highlight-regexp-function isearch-regexp-function isearch-lazy-highlight-forward isearch-forward) (unless (equal isearch-string "") - (isearch-lazy-highlight-update)))) + (setq isearch-lazy-highlight-timer + (run-with-idle-timer lazy-highlight-initial-delay nil + 'isearch-lazy-highlight-update))))) (defun isearch-lazy-highlight-search () "Search ahead for the next or previous match, for lazy highlighting. diff --git a/lisp/replace.el b/lisp/replace.el index 54b3a71..d48f4f3 100644 --- a/lisp/replace.el +++ b/lisp/replace.el @@ -2011,6 +2011,9 @@ replace-match-maybe-edit (when backward (goto-char (nth 0 match-data))) noedit) +(defvar replace-update-post-hook nil + "Function(s) to call after query-replace has found a match in the buffer.") + (defvar replace-search-function nil "Function to use when searching for strings to replace. It is used by `query-replace' and `replace-string', and is called @@ -2264,7 +2267,7 @@ perform-replace (and nonempty-match (or (not regexp-flag) (and (if backward - (looking-back search-string) + (looking-back search-string nil) (looking-at search-string)) (let ((match (match-data))) (and (/= (nth 0 match) (nth 1 match)) @@ -2318,7 +2321,8 @@ perform-replace ;; `real-match-data'. (while (not done) (set-match-data real-match-data) - (replace-highlight + (run-hooks 'replace-update-post-hook) ; Before `replace-highlight'. + (replace-highlight (match-beginning 0) (match-end 0) start end search-string regexp-flag delimited-flag case-fold-search backward) diff --git a/lisp/textmodes/ispell.el b/lisp/textmodes/ispell.el index fe27f0f..fae0549 100644 --- a/lisp/textmodes/ispell.el +++ b/lisp/textmodes/ispell.el @@ -2248,6 +2248,11 @@ ispell-pdict-save (setq ispell-pdict-modified-p nil)) +(defvar ispell-update-post-hook nil + "A normal hook invoked from the ispell command loop. +It is called once per iteration, before displaying a prompt to +the user.") + (defun ispell-command-loop (miss guess word start end) "Display possible corrections from list MISS. GUESS lists possibly valid affix construction of WORD. @@ -2315,8 +2320,10 @@ ispell-command-loop count (ispell-int-char (1+ count)))) (setq count (ispell-int-char (- count ?0 skipped)))) + (run-hooks 'ispell-update-post-hook) + ;; ensure word is visible - (if (not (pos-visible-in-window-p end)) + (if (not (pos-visible-in-window-p end nil nil t)) (sit-for 0)) ;; Display choices for misspelled word. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 05 18:16:33 2015 Received: (at 17453) by debbugs.gnu.org; 5 Dec 2015 23:16:33 +0000 Received: from localhost ([127.0.0.1]:40158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a5M49-0000ZO-6e for submit@debbugs.gnu.org; Sat, 05 Dec 2015 18:16:33 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:47294 helo=homiemail-a100.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a5M3p-0000Yg-5e for 17453@debbugs.gnu.org; Sat, 05 Dec 2015 18:16:32 -0500 Received: from homiemail-a100.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTP id BFBFB31A073; Sat, 5 Dec 2015 15:16:12 -0800 (PST) Received: from localhost.linkov.net (m91-129-116-187.cust.tele2.ee [91.129.116.187]) (Authenticated sender: jurta@jurta.org) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTPA id 8115731A070; Sat, 5 Dec 2015 15:16:11 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: Framework extending window functions for Follow Mode (etc.). Organization: LINKOV.NET References: <56444C48.5000609@gmx.at> <8737wbx9ep.fsf@mail.linkov.net> <20151117225558.GC5054@acm.fritz.box> <878u5w3zf2.fsf@mail.linkov.net> <20151118175814.GA1690@acm.fritz.box> <87egfmkea0.fsf@mail.linkov.net> <20151125193301.GI2007@acm.fritz.box> <8737vs8isw.fsf@mail.linkov.net> <20151130203723.GA24162@acm.fritz.box> <874mg33ubg.fsf@mail.linkov.net> <20151205164032.GD2698@acm.fritz.box> Date: Sun, 06 Dec 2015 01:06:05 +0200 In-Reply-To: <20151205164032.GD2698@acm.fritz.box> (Alan Mackenzie's message of "Sat, 5 Dec 2015 16:40:32 +0000") Message-ID: <87egf0ebs2.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> I see no problem for follow-mode to add follow-post-command-hook >> to both hooks. > > Because this ties Follow Mode to implementation details of isearch.el, > replace.el, and ispell.el. It is plain ugly for Follow Mode to have to > add-hook an obscure hook for every package that attempts lazy > highlighting. A hook is needed not only for lazy highlighting (in its current state), but also for every package that doesn't use the standard command loop. >> Adding a new hook is just a one-liner, but we have to find the right place >> in perform-replace to call it. I think replace-update-pre-hook should be >> called before (read-event), and replace-update-post-hook after (read-event). >> I'm not yet sure which one is needed for follow-mode to sync windows? > > At the moment there is only replace-update-post-hook. It is called after > point has been moved, but before i-l-highlight-new-loop is called. I had > to move it slightly from where your patch had put it. Yes, you've moved it to a better place. > Sorry, I made a typo there. I really meant replace-update-post-hook. > Can we somehow keep this "internal use only", so that we are not bound > somehow to keep supporting it should the `query-replace' command loop be > reformulated (as believe it should, ASAP)? The same applies to > ispell-update-post-hook, which I've been forced to introduce into > ispell.el for the same reason. isearch-update-post-hook, replace-update-post-hook, ispell-update-post-hook are not just a hack, they will stay as useful hooks even after we'll rewrite query-replace/ispell to use the standard command loop. These hooks are for convenience, for the users to be able to set in ~/.emacs, e.g.: (add-hook 'isearch-update-post-hook 'recenter) (add-hook 'replace-update-post-hook 'recenter) How would you do the same without these hooks, using only post-command-hook? > ######################################################################### > > Anyhow, here's a status update with where I am on making isearch.el and > follow.el work together: > > (i) Yesterday I rebased the scratch/follow branch on the emacs-25 branch. > (ii) I haven't yet replaced the GROUP parameter in the windows primitives > with (e.g.) `window-group-start'. > (iii) isearch.el now appears to work properly. For this, I had to swap > the order of invocation of isearch-update-post-hook and i-l-h-new-loop, > like you said. I restored i-l-h-new-loop pretty much to the way it was > prior to my experimentations. > (iv) replace.el now appears to work properly. > (v) ispell.el is more troublesome. See bug #22097. I have a problem > with ispell putting its *Choices* window at the top of the left hand > Follow Mode window. Because of FM's sorting algorithm, this causes the > two windows to be logically swapped, leading to confusing results. I > think the neatest solution would be to put *Choices* at the top of the > rightmost window, preventing this. I believe bug#22097 is easy to fix for lazy highlighting, but what you described above is more troublesome, and might require adding support for window groups to ispell.el (like you're adding it to isearch.el). From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 07 14:13:54 2015 Received: (at 17453) by debbugs.gnu.org; 7 Dec 2015 19:13:54 +0000 Received: from localhost ([127.0.0.1]:42018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a61EP-0002Dy-TD for submit@debbugs.gnu.org; Mon, 07 Dec 2015 14:13:54 -0500 Received: from mail.muc.de ([193.149.48.3]:61823) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a61E5-0002DV-GG for 17453@debbugs.gnu.org; Mon, 07 Dec 2015 14:13:52 -0500 Received: (qmail 41411 invoked by uid 3782); 7 Dec 2015 19:13:32 -0000 Received: from acm.muc.de (p5B1463E7.dip0.t-ipconnect.de [91.20.99.231]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 07 Dec 2015 20:13:31 +0100 Received: (qmail 10899 invoked by uid 1000); 7 Dec 2015 19:15:40 -0000 Date: Mon, 7 Dec 2015 19:15:40 +0000 To: Juri Linkov Subject: Re: Framework extending window functions for Follow Mode (etc.). Message-ID: <20151207191540.GD1904@acm.fritz.box> References: <20151117225558.GC5054@acm.fritz.box> <878u5w3zf2.fsf@mail.linkov.net> <20151118175814.GA1690@acm.fritz.box> <87egfmkea0.fsf@mail.linkov.net> <20151125193301.GI2007@acm.fritz.box> <8737vs8isw.fsf@mail.linkov.net> <20151130203723.GA24162@acm.fritz.box> <874mg33ubg.fsf@mail.linkov.net> <20151205164032.GD2698@acm.fritz.box> <87egf0ebs2.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87egf0ebs2.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello, Juri. On Sun, Dec 06, 2015 at 01:06:05AM +0200, Juri Linkov wrote: > >> I see no problem for follow-mode to add follow-post-command-hook > >> to both hooks. > > Because this ties Follow Mode to implementation details of isearch.el, > > replace.el, and ispell.el. It is plain ugly for Follow Mode to have to > > add-hook an obscure hook for every package that attempts lazy > > highlighting. > A hook is needed not only for lazy highlighting (in its current state), > but also for every package that doesn't use the standard command loop. Yes, I think we're in violent agreement here. [ .... ] > > Sorry, I made a typo there. I really meant replace-update-post-hook. > > Can we somehow keep this "internal use only", so that we are not > > bound somehow to keep supporting it should the `query-replace' > > command loop be reformulated (as believe it should, ASAP)? The same > > applies to ispell-update-post-hook, which I've been forced to > > introduce into ispell.el for the same reason. > isearch-update-post-hook, replace-update-post-hook, ispell-update-post-hook > are not just a hack, they will stay as useful hooks even after we'll > rewrite query-replace/ispell to use the standard command loop. These hooks > are for convenience, for the users to be able to set in ~/.emacs, e.g.: > (add-hook 'isearch-update-post-hook 'recenter) > (add-hook 'replace-update-post-hook 'recenter) First comment: this sort of thing will wreck Follow Mode, scrolling text in the current window rather than point moving forward to the next window. > How would you do the same without these hooks, using only post-command-hook? By putting #'recenter into `post-command-hook'? This should work for Isearch, and would work for Replace and Ispell if these two used the Emacs command loop. > > ######################################################################### > > Anyhow, here's a status update with where I am on making isearch.el and > > follow.el work together: > > (i) Yesterday I rebased the scratch/follow branch on the emacs-25 branch. > > (ii) I haven't yet replaced the GROUP parameter in the windows primitives > > with (e.g.) `window-group-start'. > > (iii) isearch.el now appears to work properly. For this, I had to swap > > the order of invocation of isearch-update-post-hook and i-l-h-new-loop, > > like you said. I restored i-l-h-new-loop pretty much to the way it was > > prior to my experimentations. > > (iv) replace.el now appears to work properly. > > (v) ispell.el is more troublesome. See bug #22097. I have a problem > > with ispell putting its *Choices* window at the top of the left hand > > Follow Mode window. Because of FM's sorting algorithm, this causes the > > two windows to be logically swapped, leading to confusing results. I > > think the neatest solution would be to put *Choices* at the top of the > > rightmost window, preventing this. I have indeed put *Choices* at the top of the RH window, to preserve sanity. I committed those changes, including changes to Ispell this afternoon. I think they're close to working fully. > I believe bug#22097 is easy to fix for lazy highlighting, but what you > described above is more troublesome, and might require adding support for > window groups to ispell.el (like you're adding it to isearch.el). I've put the window group stuff into ispell.el - there wasn't a lot to change. This afternoon, lack of lazy highlighting in Ispell (bug #22097) made itself noticeable again. I'll see what I can do, here. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 07 19:51:38 2015 Received: (at 17453) by debbugs.gnu.org; 8 Dec 2015 00:51:39 +0000 Received: from localhost ([127.0.0.1]:42176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a66VF-00050k-9U for submit@debbugs.gnu.org; Mon, 07 Dec 2015 19:51:37 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:37123 helo=homiemail-a100.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a66Ut-000506-A2 for 17453@debbugs.gnu.org; Mon, 07 Dec 2015 19:51:34 -0500 Received: from homiemail-a100.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTP id 68F7B31A075; Mon, 7 Dec 2015 16:51:14 -0800 (PST) Received: from localhost.linkov.net (m83-180-31-224.cust.tele2.ee [83.180.31.224]) (Authenticated sender: jurta@jurta.org) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTPA id 3F80131A073; Mon, 7 Dec 2015 16:51:13 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: Framework extending window functions for Follow Mode (etc.). Organization: LINKOV.NET References: <20151117225558.GC5054@acm.fritz.box> <878u5w3zf2.fsf@mail.linkov.net> <20151118175814.GA1690@acm.fritz.box> <87egfmkea0.fsf@mail.linkov.net> <20151125193301.GI2007@acm.fritz.box> <8737vs8isw.fsf@mail.linkov.net> <20151130203723.GA24162@acm.fritz.box> <874mg33ubg.fsf@mail.linkov.net> <20151205164032.GD2698@acm.fritz.box> <87egf0ebs2.fsf@mail.linkov.net> <20151207191540.GD1904@acm.fritz.box> Date: Tue, 08 Dec 2015 02:42:39 +0200 In-Reply-To: <20151207191540.GD1904@acm.fritz.box> (Alan Mackenzie's message of "Mon, 7 Dec 2015 19:15:40 +0000") Message-ID: <877fkpu5xc.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17453 Cc: martin rudalics , 17453@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> (add-hook 'isearch-update-post-hook 'recenter) >> (add-hook 'replace-update-post-hook 'recenter) > > First comment: this sort of thing will wreck Follow Mode, scrolling text > in the current window rather than point moving forward to the next > window. I guess a lot of other customizations will wreck Follow Mode too. >> How would you do the same without these hooks, using only post-command-hook? > > By putting #'recenter into `post-command-hook'? This should work for > Isearch, and would work for Replace and Ispell if these two used the > Emacs command loop. This will call #'recenter on every command. > I have indeed put *Choices* at the top of the RH window, to preserve > sanity. > > I committed those changes, including changes to Ispell this afternoon. I > think they're close to working fully. Yes, pretty close. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 20 07:56:59 2015 Received: (at 17453-done) by debbugs.gnu.org; 20 Dec 2015 12:56:59 +0000 Received: from localhost ([127.0.0.1]:57441 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aAdXm-0002VC-P1 for submit@debbugs.gnu.org; Sun, 20 Dec 2015 07:56:58 -0500 Received: from mail.muc.de ([193.149.48.3]:22147) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aAdXk-0002Uz-Kd for 17453-done@debbugs.gnu.org; Sun, 20 Dec 2015 07:56:57 -0500 Received: (qmail 82210 invoked by uid 3782); 20 Dec 2015 12:56:55 -0000 Received: from acm.muc.de (p579E9076.dip0.t-ipconnect.de [87.158.144.118]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 20 Dec 2015 13:56:54 +0100 Received: (qmail 26268 invoked by uid 1000); 20 Dec 2015 12:59:08 -0000 Date: Sun, 20 Dec 2015 12:59:07 +0000 To: 17453-done@debbugs.gnu.org Subject: Re: bug#17453: Acknowledgement (Isearch doesn't work properly with Follow Mode.) Message-ID: <20151220125907.GA3881@acm.fritz.box> References: <20140509224458.GA4205@acm.acm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17453-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Bug fixed in emacs-25 branch. -- Alan Mackenzie (Nuremberg, Germany). From unknown Fri Aug 22 01:03:44 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 18 Jan 2016 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator