trunk is trying to access X windows selection in -nw mode

trunk is trying to access X windows selection in -nw mode

[Giorgos Keramidas]

When running in 'emacs -nw' mode, the latest builds of trunk on my
laptop display an error in the modeline:

    X windows are not in use or not initialized

The first commit that seems to trigger this in the git mirror is:

    user:        Chong Yidong <cyd@stupidchicken.com>
    date:        Sun Aug 15 22:33:17 2010 -0400
    summary:     Let all active regions set the primary selection.

I haven't really found why 'emacs -nw' still tries to access X windows
attributes after this commit, but the (error ...) call breaks
macro-recording that uses text selection for non-X11 frames by
triggerring a bell for all selection operations.

Can we please roll back or fix this?

Re: trunk is trying to access X windows selection in -nw mode

[Chong Yidong]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> When running in 'emacs -nw' mode, the latest builds of trunk on my
> laptop display an error in the modeline:
>
>     X windows are not in use or not initialized

Could you try to figure out what code is emitting this error?  Run Emacs
in gdb with checkpoints on `error'.

Re: trunk is trying to access X windows selection in -nw mode

[Giorgos Keramidas]

On Mon, 30 Aug 2010 19:10:24 -0400, Chong Yidong <cyd@stupidchicken.com> wrote:
> Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
>
>> When running in 'emacs -nw' mode, the latest builds of trunk on my
>> laptop display an error in the modeline:
>>
>>     X windows are not in use or not initialized
>
> Could you try to figure out what code is emitting this error?  Run Emacs
> in gdb with checkpoints on `error'.

The stack trace is:

  (gdb) bt
  #0  error (m=0x81f8cd0 "X windows are not in use or not initialized") at eval.c:2035
  #1  0x080ee3fd in check_x () at xfns.c:220
  #2  0x080fac47 in Fx_own_selection_internal (selection_name=138393082, selection_value=145865153) at xselect.c:2075
  #3  0x0818e388 in Ffuncall (nargs=3, args=0xbfbfe120) at eval.c:2993
  #4  0x081c36c9 in Fbyte_code (bytestr=137023001, vector=137023021,
      maxdepth=Variable "maxdepth" is not available.
      ) at bytecode.c:679
  #5  0x0818ddf4 in funcall_lambda (fun=137022965, nargs=2, arg_vector=0xbfbfe260) at eval.c:3174
  #6  0x0818e10f in Ffuncall (nargs=3, args=0xbfbfe25c) at eval.c:3047
  #7  0x0818e5db in call2 (fn=138393058, arg1=138393082, arg2=145865153) at eval.c:2804
  #8  0x08133484 in command_loop_1 () at keyboard.c:1814
  #9  0x0818cc5b in internal_condition_case (bfun=0x8132600 <command_loop_1>, handlers=138406226,
      hfun=0x812cec0 <cmd_error>) at eval.c:1460
  #10 0x0812cb63 in command_loop_2 (ignore=138352666) at keyboard.c:1338
  #11 0x0818cd15 in internal_catch (tag=138404346, func=0x812cb40 <command_loop_2>, arg=138352666) at eval.c:1204
  #12 0x0812cd11 in command_loop () at keyboard.c:1317
  #13 0x0812d08b in recursive_edit_1 () at keyboard.c:940
  #14 0x0812d1c1 in Frecursive_edit () at keyboard.c:1002
  #15 0x08122425 in main (argc=2, argv=0xbfbfe5dc) at emacs.c:1704

  Lisp Backtrace:
  "x-own-selection-internal" (0xbfbfe124)
  "x-set-selection" (0xbfbfe260)
  (gdb)

Re: trunk is trying to access X windows selection in -nw mode

[Eli Zaretskii]

> From: Giorgos Keramidas <keramida@ceid.upatras.gr>
> Date: Tue, 31 Aug 2010 10:17:53 +0300
> Cc: emacs-devel@gnu.org
> 
> On Mon, 30 Aug 2010 19:10:24 -0400, Chong Yidong <cyd@stupidchicken.com> wrote:
> > Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
> >
> >> When running in 'emacs -nw' mode, the latest builds of trunk on my
> >> laptop display an error in the modeline:
> >>
> >>     X windows are not in use or not initialized
> >
> > Could you try to figure out what code is emitting this error?  Run Emacs
> > in gdb with checkpoints on `error'.
> 
> The stack trace is:
> 
>   (gdb) bt
>   #0  error (m=0x81f8cd0 "X windows are not in use or not initialized") at eval.c:2035
>   #1  0x080ee3fd in check_x () at xfns.c:220
>   #2  0x080fac47 in Fx_own_selection_internal (selection_name=138393082, selection_value=145865153) at xselect.c:2075
>   #3  0x0818e388 in Ffuncall (nargs=3, args=0xbfbfe120) at eval.c:2993
>   #4  0x081c36c9 in Fbyte_code (bytestr=137023001, vector=137023021,
>       maxdepth=Variable "maxdepth" is not available.
>       ) at bytecode.c:679
>   #5  0x0818ddf4 in funcall_lambda (fun=137022965, nargs=2, arg_vector=0xbfbfe260) at eval.c:3174
>   #6  0x0818e10f in Ffuncall (nargs=3, args=0xbfbfe25c) at eval.c:3047
>   #7  0x0818e5db in call2 (fn=138393058, arg1=138393082, arg2=145865153) at eval.c:2804
>   #8  0x08133484 in command_loop_1 () at keyboard.c:1814

The culprit is the code below in keyboard.c, it should never call
x-set-selection if the frame returns nil from display-selections-p
(this could be replaced with a test of the frame kind).

	  else
	    {
	      /* Even if not deactivating the mark, set PRIMARY if
		 `select-active-regions' is non-nil.  */
	      if ((EQ (Vselect_active_regions, Qonly)
		   ? EQ (CAR_SAFE (Vtransient_mark_mode), Qonly)
		   : (!NILP (Vselect_active_regions)
		      && !NILP (Vtransient_mark_mode)))
		  && !EQ (Vthis_command, Qhandle_switch_frame))
		{
		  int beg = XINT (Fmarker_position (current_buffer->mark));
		  int end = XINT (make_number (PT));
		  if (beg < end)
		    call2 (Qx_set_selection, QPRIMARY,
			   make_buffer_string (beg, end, 0));

Re: trunk is trying to access X windows selection in -nw mode

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> The culprit is the code below in keyboard.c, it should never call
> x-set-selection if the frame returns nil from display-selections-p
> (this could be replaced with a test of the frame kind).

Thanks, I've checked just such a fix.

Re: trunk is trying to access X windows selection in -nw mode

[Giorgos Keramidas]

On Tue, 31 Aug 2010 12:02:59 -0400, Chong Yidong <cyd@stupidchicken.com> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> The culprit is the code below in keyboard.c, it should never call
>> x-set-selection if the frame returns nil from display-selections-p
>> (this could be replaced with a test of the frame kind).
>
> Thanks, I've checked just such a fix.

Excellent :)

Thanks to both Eli and you