From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.devel Subject: Re: isearch, auto-composition-mode and display properties Date: Fri, 30 May 2008 16:17:59 +0200 Message-ID: <87ej7jswo8.fsf@escher.local.home> References: <878x1ee1ai.fsf@escher.local.home> <87fxvj9ur5.fsf_-_@escher.local.home> <87wsouuq7g.fsf@jurta.org> <87iqwwrxbt.fsf@escher.local.home> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1212157126 27605 80.91.229.12 (30 May 2008 14:18:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 May 2008 14:18:46 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 30 16:19:27 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K25Rp-0002zB-S3 for ged-emacs-devel@m.gmane.org; Fri, 30 May 2008 16:19:14 +0200 Original-Received: from localhost ([127.0.0.1]:38061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K25R4-0003vv-2i for ged-emacs-devel@m.gmane.org; Fri, 30 May 2008 10:18:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K25Qw-0003rn-7o for emacs-devel@gnu.org; Fri, 30 May 2008 10:18:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K25Qt-0003p7-GJ for emacs-devel@gnu.org; Fri, 30 May 2008 10:18:17 -0400 Original-Received: from [199.232.76.173] (port=33845 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K25Qt-0003p3-A8 for emacs-devel@gnu.org; Fri, 30 May 2008 10:18:15 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:33921 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K25Qs-0007MX-SB for emacs-devel@gnu.org; Fri, 30 May 2008 10:18:15 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1K25Qq-0004jd-Ug for emacs-devel@gnu.org; Fri, 30 May 2008 14:18:12 +0000 Original-Received: from i5387d3c1.versanet.de ([83.135.211.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 May 2008 14:18:12 +0000 Original-Received: from Stephen.Berman by i5387d3c1.versanet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 May 2008 14:18:12 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 81 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: i5387d3c1.versanet.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:98069 Archived-At: On Fri, 30 May 2008 10:49:10 +0200 Stephen Berman wrote: > On Sun, 24 Feb 2008 21:09:07 +0200 Juri Linkov wrote: > >>> I hope others can reproduce this problem and someone can figure out >>> what's going on. >> >> Thank you for the detailed test case. I was able to reproduce it. >> >> To debug isearch, you can instrument one of the top isearch functions >> (e.g. `isearch-repeat-forward'), open the isearch.el file in another >> frame/buffer (another frame is more preferable when debugging display >> problems like in your case), and start typing C-s in the original >> buffer. When it stops on an uninteresting place, just type `g' to >> continue execution. Use `i' to go to a deeper function. >> >> The hardest part in debugging isearch is not forget not to use isearch >> to navigate in the source buffer while edebug is active (e.g. to find >> the next function to instrument, etc :) >> >> Using this technique, it is possible to find that your trouble is cased >> by the following part of `isearch-update': >> >> ;; Keep same hscrolling as at the start of the search when possible >> (let ((current-scroll (window-hscroll))) >> (set-window-hscroll (selected-window) isearch-start-hscroll) >> (unless (pos-visible-in-window-p) >> (set-window-hscroll (selected-window) current-scroll))) >> >> Removing this part eliminates the bug you reported. Unfortunately, >> I have no idea how to fix this since this depends on the details >> how the display engine works. > > I'd like to return to this. Assuming a fix at the display level is too > difficult or laborious, I wonder whether the above code really does what > the comment says. In fact, I'm not sure what the comment is intending > to achieve. I tested the code by starting isearch with different > horizontal scrolling positions set, both with and without the above > code, and saw no difference in behavior or resulting hscroll position. > What difference is expected and what do you have to do to see it? > Moreover, unless I misunderstand the manual, it looks like the above > will always leave the hscroll position at (window-hscroll) (which is > what my tests resulted in): > > (elisp) Window Start: > > The `pos-visible-in-window-p' function considers only vertical > scrolling. If POSITION is out of view only because WINDOW has > been scrolled horizontally, `pos-visible-in-window-p' returns > non-`nil' anyway. > > Is it possible for (pos-visible-in-window-p) to return nil after an > isearch? Sorry, much of what I wrote above is gibberish, due to insufficient testing and not paying enough attention. As should have been clear to me, (pos-visible-in-window-p) returns nil during isearch precisely when the next occurrence of the search term is below (window-end) (d'oh!). And it is exactly at this point in the code that the problem I reported arises (but it doesn't happen every time p-v-i-w-p returns nil; I'll try to use gdb to find out more). If the unless-sexp is eliminated, isearch works as expected in the configuration given in my OP. What still confuses me, however, is whether the unless-clause has a noticeable effect. When isearch-mode is invoked, isearch-start-hscroll gets the current hscroll position, as returned by (window-hscroll). IIUC, if, in the course of the isearch, the hscroll position changes, the above code resets it to the initial value isearch-start-hscroll, unless the next search term occurrence is beyond the visible window, in which case the hscroll position becomes the new return value of (window-hscroll). I tried to test for this, but I could see no difference: whether or not the next occurrence is in the visible window, and whether or not the unless-sexp (or indeed the entire let-sexp) is present, the window scrolls as required by isearch, and stays in the current hscroll position upon exiting isearch, or returns to the initial hscroll position upon cancelling isearch. Can anyone else confirm this, or have I again made a mistake in my tests or misunderstood the code? And again, if I haven't made a mistake and the unless-sexp (or the entire let-sexp) has no effect, can it be removed? Steve Berman