bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#20734: 25.0.50; "Args out of range" with help-window-select t


From: Eli Zaretskii
Subject: bug#20734: 25.0.50; "Args out of range" with help-window-select t
Date: Fri, 05 Jun 2015 16:45:32 +0300

> From: Nicolas Richard <youngfrog@members.fsf.org>
> Cc: 20734@debbugs.gnu.org
> Date: Fri, 05 Jun 2015 11:25:35 +0200
> 
> 1. run under gdb
> 2. follow the recipe up to the point where I type "C-h f if", but don't
>    hit RET
> 3. then go to gdb window
> 4. hit C-z to put a breakpoint in adjust_point_for_property
> 5. continue
> 6. go back to emacs and hit RET
> 
> Now back to gdb :
> (gdb) p XBUFFER(XWINDOW(selected_window)->contents)->name_
> $1 = 143880388
> (gdb) xpr
> Lisp_String
> $2 = (struct Lisp_String *) 0x89370c0
> "*Help*"

You could also do this, which is slightly easier:

 (gdb) p XWINDOW(selected_window)->contents
 (gdb) xtype # make sure it's a buffer
 (gdb) xbuffer

> > And please note that the conditions in the 'if' clause that determine
> > whether adjust_point_for_property is called freely manipulate values
> > of current_buffer and PT, so perhaps the solution is add there a
> > condition that selected_window's buffer and current_buffer are equal,
> > such that in the case in point adjust_point_for_property is not called
> > at all.
> 
> In command_loop_1 ?

Yes.

> I can more or less follow the code step by step, but I don't really
> understand it. The only thing I'm now almost 100% confident is that in
> this call (found in adjust_point_for_property) :
>   get_char_property_and_overlay
>       (make_number (PT), Qdisplay, selected_window,
>        &overlay))
> PT refers to current_buffer, which is different from the buffer in
> selected_window in the situation I encountered.

Yes, that's the bug.  But the real problem is that we've switched
windows temporarily, and we shouldn't move point in the current buffer
at all when we do that.

> > To answer your question directly, it should be possible to compute the
> > (Lisp integer) value of point in the selected window as either
> 
> Thanks. This works for me, but is it TRT ?

No, I think we shouldn't call adjust_point_for_property in this case
at all.  Can you see if adding

  && EQ (XWINDOW (selected_window)->contents, current_buffer)

to the condition that guards the call to adjust_point_for_property
fixes the problem?  I.e., instead of this (after the label 'finalize'):

      if (current_buffer == prev_buffer
          && last_point_position != PT
          && NILP (Vdisable_point_adjustment)
          && NILP (Vglobal_disable_point_adjustment))

the condition should read

      if (current_buffer == prev_buffer
          && EQ (XWINDOW (selected_window)->contents, current_buffer)
          && last_point_position != PT
          && NILP (Vdisable_point_adjustment)
          && NILP (Vglobal_disable_point_adjustment))

IOW, if the selected window's buffer is not the current buffer, we
shouldn't be adjusting point in the current buffer at all.

Thanks.





reply via email to

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