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

Previous Next

Full log

Message #20 received at 20734 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Richard <youngfrog <at> members.fsf.org>
Cc: 20734 <at> debbugs.gnu.org
Subject: Re: 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 <at> members.fsf.org>
> Cc: 20734 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.