bug#15261: 24.2; Cursor not visible while moving point in transient mark mode

bug#15261: 24.2; Cursor not visible while moving point in transient mark mode

[RICHARD MUNITZ (BLOOMBERG/ 731 LEXIN)]

--text follows this line--
This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgement at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

>>>
The basic problem is that if I set mark and then quickly move the cursor
around in any direction with a reasonable rapid sequence of cursor movement keystrokes,
the cursor becomes invisible and there is no highlighting until I stop
typing for a moment. So there is no visual feedback on where point is and it
greatly slows down movement to the desired destination.  It seems that I need to pause about 1/2
second between keystrokes for the cursor and highlighting to be rendered on
the screen.
This is reproducible:
Start 'emacs -Q';
C-SPC (to set mark at the end of the buffer)
Then in somewhat rapid succession, perhaps 1/4 second apart, type C-p C-p C-p C-p
There is no evidence of movement while the C-p's are being typed that point is
moving up the screen until you stop typing and point suddenly jumps 3
lines up and it shows all lines highlighted.
>>>


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/opt/swt/install/emacs-24.2/share/emacs/24.2/etc/DEBUG.


In GNU Emacs 24.2.1 (sparc-sun-solaris2.10, GTK+ Version 2.16.5)
 of 2012-10-12 on nysbldo5
Windowing system distributor `Hummingbird - Open Text', version 11.0.13830
Configured using:
 `configure '--prefix=/opt/swt/install/emacs-24.2' 'CC=gcc -m32
 -D_FILE_OFFSET_BITS=64' 'CFLAGS=-I. -I/opt/swt/include'
 'LDFLAGS=-L/opt/swt/lib/sparcv9 -R/opt/swt/lib/sparcv9
 -Wl,-R/opt/swt/lib/sparcv9 -L/opt/swt/lib -R/opt/swt/lib
 -Wl,-R/opt/swt/lib''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-SPC C-p C-p C-p C-p C-p <escape> > C-SPC C-p C-p 
C-p C-p <escape> > C-SPC C-p C-p C-p C-p C-n C-n C-n 
C-n C-p C-p C-p C-p <down-mouse-1> <mouse-1> C-p C-p 
C-p C-p C-n C-n C-n C-n C-SPC C-p C-p C-p C-p <help-echo> 
<escape> > C-SPC <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> C-p C-p C-p <escape> > C-p 
C-p C-p C-p C-p <escape> > C-p C-p C-p C-p C-p C-p 
<escape> > <down-mouse-1> <mouse-1> <down-mouse-1> 
<mouse-1> C-p C-p C-p C-p C-n C-n C-n C-n C-SPC C-p 
C-p C-p C-p <help-echo> <down-mouse-1> <mouse-1> C-h 
C-a <help-echo> <help-echo> C-h a b u g <return> C-x 
1 C-h a <escape> C-g C-h <escape> C-h C-g C-g C-h C-a 
C-h C-b C-h b C-h a b u g SPC r e p o r t <return> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <menu-bar> <help-menu> 
<send-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
byte-code: Beginning of buffer
Mark activated [4 times]
byte-code: Beginning of buffer [3 times]
Mark activated
Type C-x 1 to remove help window.  
Quit [2 times]
Type C-x 1 to delete the help window, C-M-v to scroll help.
Type C-x 4 C-o RET to restore the other window.  

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils kmacro two-column iso-transl help-mode
easymenu view apropos time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dynamic-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

bug#15261: 24.2; Cursor not visible while moving point in transient mark mode

[Eli Zaretskii]

> Date: Tue, 3 Sep 2013 18:28:14 -0000
> From: "RICHARD MUNITZ (BLOOMBERG/ 731 LEXIN)" <rmunitz1@bloomberg.net>
> 
> Start 'emacs -Q';
> C-SPC (to set mark at the end of the buffer)
> Then in somewhat rapid succession, perhaps 1/4 second apart, type C-p C-p C-p C-p
> There is no evidence of movement while the C-p's are being typed that point is
> moving up the screen until you stop typing and point suddenly jumps 3
> lines up and it shows all lines highlighted.

What you describe sounds like redisplay cannot keep up with your
commands.  Unless the machine is extremely old and slow, I don't see
how this is possible in such a simple scenario.  FWIW, I cannot
reproduce that on my machine.

bug#15261: 24.2; Cursor not visible while moving point in transient mark mode

[Josh]

On Tue, Sep 3, 2013 at 12:25 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 3 Sep 2013 18:28:14 -0000
>> From: "RICHARD MUNITZ (BLOOMBERG/ 731 LEXIN)" <rmunitz1@bloomberg.net>
>>
>> Start 'emacs -Q';
>> C-SPC (to set mark at the end of the buffer)
>> Then in somewhat rapid succession, perhaps 1/4 second apart, type C-p C-p C-p C-p
>> There is no evidence of movement while the C-p's are being typed that point is
>> moving up the screen until you stop typing and point suddenly jumps 3
>> lines up and it shows all lines highlighted.
>
> What you describe sounds like redisplay cannot keep up with your
> commands.  Unless the machine is extremely old and slow, I don't see
> how this is possible in such a simple scenario.  FWIW, I cannot
> reproduce that on my machine.

The windowing system "`Hummingbird - Open Text', version 11.0.13830",
suggests that the OP is connecting to an Emacs running on a Solaris
machine from a Windows-based X server[0] across a network connection
with unknown bandwidth and latency characteristics.  The reported
symptoms seem consistent with a laggy network connection to me.

[0] http://connectivity.opentext.com/products/exceed-products.aspx

bug#15261: 24.2; Cursor not visible while moving point in transient mark mode

[RICHARD MUNITZ (BLOOMBERG/ 731 LEXIN)]

Client and server machine are LAN connected.  Yes, it is a Solaris server.  A tracert from my machine to the server shows 7 hops, but all under 1ms latency.  
The reported behavior consistently occurs 100% of the time and has for the 4 weeks I have been working in this environment - including off-hours.  So I don't think bandwidth is a factor either.  
Note that Bloomberg's core business is distributing real-time market data to the financial industry, so they are rather obsessive about high performance networks.
For comparison, I just tried running gvim and repeated the same "highlight text" test (from top of file I hit "v" (visual mode) and then pressed and held the "j" (down) key. gvim was able to continuously move the cursor and highlight line after line, scrolling screen after screen without ever freezing up. 



----- Original Message -----
From: josh@foxtail.org
To: eliz@gnu.org
Cc: RICHARD MUNITZ (BLOOMBERG/ 731 LEXIN), 15261@debbugs.gnu.org
At: Sep  4 2013 11:07:40

On Tue, Sep 3, 2013 at 12:25 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 3 Sep 2013 18:28:14 -0000
>> From: "RICHARD MUNITZ (BLOOMBERG/ 731 LEXIN)" <rmunitz1@bloomberg.net>
>>
>> Start 'emacs -Q';
>> C-SPC (to set mark at the end of the buffer)
>> Then in somewhat rapid succession, perhaps 1/4 second apart, type C-p C-p C-p C-p
>> There is no evidence of movement while the C-p's are being typed that point is
>> moving up the screen until you stop typing and point suddenly jumps 3
>> lines up and it shows all lines highlighted.
>
> What you describe sounds like redisplay cannot keep up with your
> commands.  Unless the machine is extremely old and slow, I don't see
> how this is possible in such a simple scenario.  FWIW, I cannot
> reproduce that on my machine.

The windowing system "`Hummingbird - Open Text', version 11.0.13830",
suggests that the OP is connecting to an Emacs running on a Solaris
machine from a Windows-based X server[0] across a network connection
with unknown bandwidth and latency characteristics.  The reported
symptoms seem consistent with a laggy network connection to me.

[0] http://connectivity.opentext.com/products/exceed-products.aspx

bug#15261: Re: bug#15261: 24.2; Cursor not visible while moving point in transient mark mode

[Eli Zaretskii]

> Date: Wed, 4 Sep 2013 15:47:56 -0000
> From: "RICHARD MUNITZ (BLOOMBERG/ 731 LEXIN)" <rmunitz1@bloomberg.net>
> Cc: 15261@debbugs.gnu.org
> 
> Client and server machine are LAN connected.  Yes, it is a Solaris server.  A tracert from my machine to the server shows 7 hops, but all under 1ms latency.  
> The reported behavior consistently occurs 100% of the time and has for the 4 weeks I have been working in this environment - including off-hours.  So I don't think bandwidth is a factor either.  
> Note that Bloomberg's core business is distributing real-time market data to the financial industry, so they are rather obsessive about high performance networks.

Does the problem happen for you when you run Emacs locally on that
machine?  Or does it only happen in this particular configuration,
when you use Exceed to access a Solaris server from a Windows machine?

> For comparison, I just tried running gvim and repeated the same "highlight text" test (from top of file I hit "v" (visual mode) and then pressed and held the "j" (down) key. gvim was able to continuously move the cursor and highlight line after line, scrolling screen after screen without ever freezing up. 

Comparisons with gvim are meaningless, because there's no primitive
"highlight this text" operation that both Emacs and gvim use.  Each
one of them highlights text using very different methods.  In Emacs,
the portion of the text that is highlighted is actually fully
redisplayed.

bug#15261: 24.2; Cursor not visible while moving point in transient mark mode

[Josh]

On Wed, Sep 4, 2013 at 8:47 AM, RICHARD MUNITZ (BLOOMBERG/ 731 LEXIN)
<rmunitz1@bloomberg.net> wrote:
> Client and server machine are LAN connected.  Yes, it is a Solaris server.  A tracert from my machine to the server shows 7 hops, but all under 1ms latency.

That's nice, but IP-level latency says nothing about the latency
at higher layers.  For troubleshooting purposes, you might consider
installing Cygwin on your Windows machine and checking whether
you observe the same behavior when you run the Solaris Emacs
in conjunction with the Cygwin X server instead of Exceed.  I would
expect that experiment to shed some light on whether the behavior
you reported is resulting from an issue with Exceed or something to
do with the remote system.

bug#15261: Re: bug#15261: 24.2; Cursor not visible while moving point in transient mark mode

[RICHARD MUNITZ (BLOOMBERG/ 731 LEXIN)]

When I log in to the Solaris server through a PuTTY client, I do not experience the problem.  The problem does occur within the Exceed X terminal window if I start Emacs with the -nw option.

----- Original Message -----
From: eliz@gnu.org
To: RICHARD MUNITZ (BLOOMBERG/ 731 LEXIN)
Cc: 15261@debbugs.gnu.org, josh@foxtail.org
At: Sep  4 2013 16:22:06

> Date: Wed, 4 Sep 2013 15:47:56 -0000
> From: "RICHARD MUNITZ (BLOOMBERG/ 731 LEXIN)" <rmunitz1@bloomberg.net>
> Cc: 15261@debbugs.gnu.org
> 
> Client and server machine are LAN connected.  Yes, it is a Solaris server.  A tracert from my machine to the server shows 7 hops, but all under 1ms latency.  
> The reported behavior consistently occurs 100% of the time and has for the 4 weeks I have been working in this environment - including off-hours.  So I don't think bandwidth is a factor either.  
> Note that Bloomberg's core business is distributing real-time market data to the financial industry, so they are rather obsessive about high performance networks.

Does the problem happen for you when you run Emacs locally on that
machine?  Or does it only happen in this particular configuration,
when you use Exceed to access a Solaris server from a Windows machine?

> For comparison, I just tried running gvim and repeated the same "highlight text" test (from top of file I hit "v" (visual mode) and then pressed and held the "j" (down) key. gvim was able to continuously move the cursor and highlight line after line, scrolling screen after screen without ever freezing up. 

Comparisons with gvim are meaningless, because there's no primitive
"highlight this text" operation that both Emacs and gvim use.  Each
one of them highlights text using very different methods.  In Emacs,
the portion of the text that is highlighted is actually fully
redisplayed.

bug#15261: 24.2; Cursor not visible while moving point in transient mark mode

[Lars Ingebrigtsen]

"RICHARD MUNITZ (BLOOMBERG/ 731 LEXIN)" <rmunitz1@bloomberg.net> writes:

> The basic problem is that if I set mark and then quickly move the cursor
> around in any direction with a reasonable rapid sequence of cursor
> movement keystrokes,
> the cursor becomes invisible and there is no highlighting until I stop
> typing for a moment. So there is no visual feedback on where point is and it
> greatly slows down movement to the desired destination.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Are you still seeing this issue in more recent versions of Emacs?

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

bug#15261: 24.2; Cursor not visible while moving point in transient mark mode

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Are you still seeing this issue in more recent versions of Emacs?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

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

bug#15261: Re: bug#15261: 24.2; Cursor not visible while moving point in transient mark mode

[Eli Zaretskii]

Please keep the bug address on the CC list.

> Date: Wed, 4 Sep 2013 14:23:59 -0000
> From: "RICHARD MUNITZ (BLOOMBERG/ 731 LEXIN)" <rmunitz1@bloomberg.net>
> 
> Thanks for the quick response.  Here is some more info.
> 
> The machine itself is a not so old multi-core server.  However, I am accessing it through Exceed onDemand Client 8 from a Windows desktop machine. And it doesn't matter which server I connect to.  Most likely, this client is a contributor to the problem.  
> If Emacs is not currently highlighting, the cursor moves instantaneously in response to rapid individual keystrokes as fast as I can type them.  However, if I press and hold say C-n, the cursor will move down line by line perhaps 10-30 or so times but then freeze for a while and finally reappear whenever I take my hands off the keyboard or at the bottom of the buffer if I don't release the key.

Thanks for the details.

It indeed sounds like Exceed is an important factor here.