GNU bug report logs - #16315
Slow paste

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16315 in the body.
You can then email your comments to 16315 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Perry Smith <pedzsan <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Slow paste
Date: Wed, 1 Jan 2014 09:42:20 -0600

[Message part 1 (text/plain, inline)]

Hi,

I have a Mac (10.8.5) running JollysFastVNC (1.48) viewing a RealVNC server (5.0.1) on AIX (6.1 TL08 SP03) running emacs (24.3).

When I copy from a Mac window and paste into emacs (yank), there is a long delay.  When I started seriously testing, it was always 5 seconds but I have memories that sometimes it was much longer.  I'm calling these memories "false" at this point.

I believe it started when emacs 24 was being developed but I'm not sure.  I know the issue existed in 24.2 and did not exist in emacs 23 that I was using but I don't recall which subversion that was.

I've turned on TRACE_SELECTION in xselect.c and I've also duplicated those macros in keyboard.c and process.c.  When I start emacs -q I get this output:

10748140: get_input_pending returning 0
10748140: last check: read_kdb=-1 NILP(wait_for_cell):1
10748140: get_input_pending returning 0
10748140: no_avail:0
10748140: pselect 2

followed by a half second pause.  This is the normal polling of the input (I guess its normal).  I go to a Mac window, select some text, then hit command-C to copy it into the cut buffer, then select the VNC window (where emacs is already the active window) and hit control-Y to paste.

I get:

10748140: get_input_pending returning 1
10748140: get_input_pending returning 1
10748140: Get selection UTF8_STRING, type _EMACS_TMP_
10748140:   Start waiting 5 secs for SelectionNotify
10748140: last check: read_kdb=0 NILP(wait_for_cell):0
10748140: Received SelectionNotify
10748140: get_input_pending returning 0
10748140: no_avail:0
10748140: pselect 2

followed by a 5 second pause, then I get

10748140:   Got event = 1
10748140: Reading selection data
10748140: Read 7 bytes from property _EMACS_TMP_
10748140:   Delete property _EMACS_TMP_

and then I see the text show up in the emacs window.  I *think* what is "wrong" here is in this case, get_input_pending is actually pulling the text out and via the SelectionNotify handler placing the text into reading_selection_reply but then returns zero because, at that point in time, there is no input to be read.  Thus this if test, is not true:

     if ((read_kbd || !NILP (wait_for_cell))
	  && detect_input_pending ())

I'm thinking that after detect_input_pending is called in wait_reading_process_output, another two lines like this:

     if (! NILP (wait_for_cell) && ! NILP (XCAR (wait_for_cell)))
	break;

should be added before the if (!no_avail) line (around line 4612 in the copy I am looking at.

I made this change in my copy and so far, it seems to work.

Perry Smith

[signature.asc (application/pgp-signature, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Perry Smith <pedzsan <at> gmail.com>
Cc: 16315 <at> debbugs.gnu.org
Subject: Re: bug#16315: Slow paste
Date: Sun, 06 Dec 2020 16:11:54 +0100

Perry Smith <pedzsan <at> gmail.com> writes:

> When I copy from a Mac window and paste into emacs (yank), there is a
> long delay.  When I started seriously testing, it was always 5 seconds
> but I have memories that sometimes it was much longer.  I'm calling
> these memories "false" at this point.

[...]

> and then I see the text show up in the emacs window.  I *think* what
> is "wrong" here is in this case, get_input_pending is actually pulling
> the text out and via the SelectionNotify handler placing the text into
> reading_selection_reply but then returns zero because, at that point
> in time, there is no input to be read.  Thus this if test, is not
> true:
>
>      if ((read_kbd || !NILP (wait_for_cell))
> 	  && detect_input_pending ())
>
> I'm thinking that after detect_input_pending is called in
> wait_reading_process_output, another two lines like this:
>
>      if (! NILP (wait_for_cell) && ! NILP (XCAR (wait_for_cell)))
> 	break;
>
> should be added before the if (!no_avail) line (around line 4612 in
> the copy I am looking at.
>
> I made this change in my copy and so far, it seems to work.

(This bug report unfortunately got no response at the time.)

The wait_reading_process_output function has changed a bit over the
years since this was first reported.  Are you still seeing this issue in
more recent Emacs versions?

If so, could you include a proposed patch?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Perry Smith <pedzsan <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16315 <at> debbugs.gnu.org
Subject: Re: bug#16315: Slow paste
Date: Sun, 6 Dec 2020 17:15:51 -0600

I no longer work as the initial bug report said.  I’m not using AIX, RealVNC,
nor JollysFastVNC.  The original report had a change which I don’t recall
not working but if I’m the only person reporting the issue, I would just close
it and leave sleeping dogs lie.

> On Dec 6, 2020, at 9:11 AM, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> 
> Perry Smith <pedzsan <at> gmail.com> writes:
> 
>> When I copy from a Mac window and paste into emacs (yank), there is a
>> long delay.  When I started seriously testing, it was always 5 seconds
>> but I have memories that sometimes it was much longer.  I'm calling
>> these memories "false" at this point.
> 
> [...]
> 
>> and then I see the text show up in the emacs window.  I *think* what
>> is "wrong" here is in this case, get_input_pending is actually pulling
>> the text out and via the SelectionNotify handler placing the text into
>> reading_selection_reply but then returns zero because, at that point
>> in time, there is no input to be read.  Thus this if test, is not
>> true:
>> 
>>     if ((read_kbd || !NILP (wait_for_cell))
>> 	  && detect_input_pending ())
>> 
>> I'm thinking that after detect_input_pending is called in
>> wait_reading_process_output, another two lines like this:
>> 
>>     if (! NILP (wait_for_cell) && ! NILP (XCAR (wait_for_cell)))
>> 	break;
>> 
>> should be added before the if (!no_avail) line (around line 4612 in
>> the copy I am looking at.
>> 
>> I made this change in my copy and so far, it seems to work.
> 
> (This bug report unfortunately got no response at the time.)
> 
> The wait_reading_process_output function has changed a bit over the
> years since this was first reported.  Are you still seeing this issue in
> more recent Emacs versions?
> 
> If so, could you include a proposed patch?
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Perry Smith <pedzsan <at> gmail.com>
Cc: 16315 <at> debbugs.gnu.org
Subject: Re: bug#16315: Slow paste
Date: Mon, 07 Dec 2020 00:16:54 +0100

Perry Smith <pedzsan <at> gmail.com> writes:

> I no longer work as the initial bug report said.  I’m not using AIX, RealVNC,
> nor JollysFastVNC.  The original report had a change which I don’t recall
> not working but if I’m the only person reporting the issue, I would just close
> it and leave sleeping dogs lie.

OK; doesn't sound like we'll make further progress here, so I'm closing
this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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