[Top][All Lists]

[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 10:49:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

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

The above code was added by this change:

2001-12-15  Richard M. Stallman  <address@hidden>

        * isearch.el (isearch-start-hscroll): New variable.
        (isearch-mode): Set isearch-start-hscroll.
        (isearch-update): Restore original hscrolling if possible.

I searched the emacs-devel, bug, and help archives prior to this change
but found no relevant posts.  If the above code either doesn't do what
it was intended for, or if it doesn't make a difference in current
Emacs, could it be eliminated?  That would at least work around the
still existing problem raised by my OP.  Or if the code is still needed,
can someone explain it to me and provide a concrete example where it

Steve Berman

reply via email to

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