[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.