emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: isearch, auto-composition-mode and display properties


From: Stephen Berman
Subject: Re: isearch, auto-composition-mode and display properties
Date: Fri, 30 May 2008 16:17:59 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

On Fri, 30 May 2008 10:49:10 +0200 Stephen Berman <address@hidden> wrote:

> On Sun, 24 Feb 2008 21:09:07 +0200 Juri Linkov <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]