[SOLVED] Emacs + rxvt-unicode Cursor Bug

battlepanic · 2011-11-16 16:12:40

When running emacs inside of a rxvt-unicode terminal, pressing the spacebar advances the cursor as it should, but sometimes it does not erase the cursor from it's previous position. Entering a third character will finally make this superfluous cursor disappear.

I have found references to similar issues in an Ubuntu bug report and a livejournal post, both of which date back to 2008. I am not sure if these issues are directly related or just similar in appearance. I seem to recall having similar issues with the cursor under emacs around three years ago when I was running Ubuntu and gnome-terminal.

Has anyone else noticed this? It's quite distracting when I'm typing in emacs and I've finally become annoyed enough to get this ball rolling.

Duplicating the Bug

Open a rxvt-unicode terminal and launch emacs with the following comand:
```
emacs -nw
```
Create a new emacs buffer named "foo".
Switch the buffer "foo" to "text-mode".
Turn on the "visual-line-mode" minor mode.
Type the following into the emacs buffer, replacing <space> with the actual whitespace (i.e. spacebar) character:
```
1234<space>1234<space>1234<space>
```

The third space will advance the cursor but not erase the cursor from its previous position, making it look twice as wide. Entering a third character will advance the cursor once more, and things will look normal again.

Failed Workarounds

In my attempt to understand the problem, I have tried a few things which don't seem to help.

Setting the TERM environment variable to various values including "linux", "screen", "vt100", "vt102", etc.
Turning cursor blinking on and off in the rxvt-unicode configuration.

Successful Workarounds

I have discovered a few workarounds, which may give some clues as to the root of the problem.

If I use rxvt-unicode to launch an instance of Gnu Screen and run emacs inside of that, the problem disappears.
If I run emacs emacs inside of an xterm instead of rxvt-unicode the problem disappears.
If I set column-number-mode in emacs as suggested by the aforementioned livejournal post, the problem will also disappear.

Last edited by battlepanic (2011-11-21 20:00:53)

examon · 2011-11-16 22:41:56

"1234<space>1234<space>1234<space>" works fine with my urxvt and emacs -nw

battlepanic · 2011-11-17 00:29:44

examon, thanks for trying this.

Would you be able to post the version number you are running for the following packages?

emacs
rxvt-unicode
ncurses

Also, also can you post your rxvt-unicdoe and emacs .Xdefaults configuration as well as the value of your TERM environment variable?

Last edited by battlepanic (2011-11-17 00:43:13)

ryuslash · 2011-11-17 08:52:34

No problem here either, does this also happen with

emacs -q -nw

and

emacs -Q -nw

?

examon · 2011-11-17 10:43:11

battlepanic wrote:

examon, thanks for trying this.
Would you be able to post the version number you are running for the following packages?
emacs
rxvt-unicode
ncurses
Also, also can you post your rxvt-unicdoe and emacs .Xdefaults configuration as well as the value of your TERM environment variable?

emacs: 23.3.a-3
rxvt-unicode: 9.12-1
ncurses: 5.9-2

bashrc: http://goo.gl/jghrI
emacs: http://goo.gl/KUBpP
xdefaults: http://goo.gl/yMueq

battlepanic · 2011-11-17 14:50:55

examon wrote:

emacs: 23.3.a-3
rxvt-unicode: 9.12-1
ncurses: 5.9-2
bashrc: http://goo.gl/jghrI
emacs: http://goo.gl/KUBpP
xdefaults: http://goo.gl/yMueq

examon, I have the same versions installed and I have now installed your config files. I have narrowed the problem somewhat. When emacs starts, if I switch to a new buffer named "foo" the buffer is in fundamental-mode by default and I don't seem to get the problem, except occasionally when backspacing over characters. However, if I switch the buffer to text-mode with visual-line-mode also enabled, the problem shows up again. The problem also shows up if I set the buffer to other modes such as c-mode or lisp-mode.

Can you try the following and let me know what you're getting?

Start emacs and create a new buffer named "foo"
Switch the buffer to "text-mode"
Add the "visual-line" minor mode
Enter the following text
```
1234<space>1234<space>1234<space>
```

With your setup, I am still able to reproduce the problem by following the above steps. I've amended my original post to specify a mode that the emacs buffer must be in in order to duplicate the bug.

examon · 2011-11-17 17:21:37

battlepanic wrote:

examon wrote:
emacs: 23.3.a-3
rxvt-unicode: 9.12-1
ncurses: 5.9-2
bashrc: http://goo.gl/jghrI
emacs: http://goo.gl/KUBpP
xdefaults: http://goo.gl/yMueq
examon, I have the same versions installed and I have now installed your config files. I have narrowed the problem somewhat. When emacs starts, if I switch to a new buffer named "foo" the buffer is in fundamental-mode by default and I don't seem to get the problem, except occasionally when backspacing over characters. However, if I switch the buffer to text-mode with visual-line-mode also enabled, the problem shows up again. The problem also shows up if I set the buffer to other modes such as c-mode or lisp-mode.
Can you try the following and let me know what you're getting?
Start emacs and create a new buffer named "foo"
Switch the buffer to "text-mode"
Add the "visual-line" minor mode
Enter the following text
1234<space>1234<space>1234<space>
With your setup, I am still able to reproduce the problem by following the above steps. I've amended my original post to specify a mode that the emacs buffer must be in in order to duplicate the bug.

OK, now I see exactly the same problem as you. When I hit 3th <space> there is superfluous cursor.

battlepanic · 2011-11-18 00:06:41

examon, thanks for your help in ironing out the details.

I've just tested aterm, eterm, xterm, rxvt, mrxvt, as well as gnome-terminal and none of them exhibit this behavior. It's starting to look like the problem lies with rxvt-unicode.

I'd be interested to hear from other rxvt-unicode users to see if they can successfully reproduce the bug.

battlepanic · 2011-11-18 02:33:29

I spoke with someone familiar with rxvt-unicode and got some answers. It seems that this is likely related to tab characters being output instead of spaces which may be an emacs optimization of some sort. Turning on the +ptab switch when invoking rxvt-unicode seems to elimnate the issue. A log of my discussion follows for anyone curious.

< __OoO__ > battlp: emacs outputs a tab character
< __OoO__ > battlp: which is "wide"
< __OoO__ > battlp: so you don't see an extra cursor, just the cursor 
            itself is wider
< __OoO__ > battlp: you can probably work around this emacs issue by
            using "+ptab" when strating urxvt
<  battlp > __OoO__: interesting.  Is this "wide" cursor a unique
            feature of urxvt?  I've tested all the other terms I can
            think of and haven't seen the same thing.
< __OoO__ > any temrinal has this
< __OoO__ > but only urxvt can store tabs
< __OoO__ > thats mostly useful when you want to paste text and want
            tabs intact
< __OoO__ > because other terminals always convert tabs to whitespace
< __OoO__ > sorry, spaces
<  battlp > Not your domain, I know, but any clue why emacs would be
            spitting a tab in this plain "text" mode.  It seems
            bizarre.
< __OoO__ > tab is both a tab character as you are used to
< __OoO__ > as well as a cursor movement
< __OoO__ > for emacs, it's probably an optimization
< __OoO__ > 9000 cpu cycles wasted to avoid an extra space going over
            your serial line
< __OoO__ > on second thought, its pretty bizarre, because thereis
            only one space
< __OoO__ > but then, can happen if your screen engine it too
            intelligent
<  battlp > I also can't predict which spaces will do this.  Running
            emacs inside of screen eliminates the issue, to, which I
            also don't understand.
< __OoO__ > likely, screen's engine isn't so cool and uses plain old 
            spaces or cursor movements
< __OoO__ > which spaces - probably the ones falling directly before a 
            tab boundary, i.e. at 7th, 15th etc.
< __OoO__ > column
<  battlp > That sounds like it might be the spots where I'm seeing it. 
            Turning on emacs' column-number-mode Make it disappear for 
            the most part, except when backspacing.
< __OoO__ > so will +ptab, which tells urxvt to treat tab as a cursor 
            movement only
<  battlp > Just tried to measure it with ruler-mode and of course that 
            makes it disappear as well.
<  battlp > Yep, +ptab makes it go away.

Arch Linux

#1 2011-11-16 16:12:40