Re: [dwm] [ANNOUNCE] dvtm-0.5
On Sun, Feb 08, 2009 at 05:24:52PM +0800, bill lam wrote: On Mon, 26 Jan 2009, Marc Andre Tanner wrote: * Scrollback support By default 500 lines scrollback history is preserved, this can be changed in config.h or overridden by the -h command line option at runtime. Scrolling is done with Mod+PageUp and Mod+PageDown. I would like to use shift+pageup/down provided by xterm, is there any option to use that function directly, instead of dvtm's mod+pageup (rather inconvenient when scrollback continuously) The xterm functionality should obviously still work but doesn't make that much sense because it will scroll the whole display area and not just the currently focused dvtm window. Or would you just like to use the same key combination as in xterm? This can be adjusted in config.h, however I doubt that shift+Page{Up,Down} will work. Regards, Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dwm] [ANNOUNCE] dvtm-0.5
On Fri, Feb 06, 2009 at 10:33:10AM +0800, bill lam wrote: On Thu, 05 Feb 2009, Marc Andre Tanner wrote: On Wed, Feb 04, 2009 at 10:35:48AM +0800, bill lam wrote: On Tue, 03 Feb 2009, Marc Andre Tanner wrote: This should now be fixed in current git HEAD. I will probably release dvtm-0.5.1 next weekend. Thanks for the report. I you have time, will you also test the screen redraw problem. When I use vim to edit two files and scroll up and down, it did not redraw properly. What do you mean exactly? I can't reproduce the redraw problem. Do you simply open a file with vim and then :split to edit another one? And after scrolling within vim with page-{up,down} something is wrong? I open a file with syntax coloring eg, a tex, :split and use arrow keys to scroll up and down continuously. Some lines were not redraw. It also happen when :only albeit not so noticeable. I run dvtm inside xterm, and timeout for vim :set timeout timeoutlen=2000 ttimeoutlen=200 Enclosed herewith the attachment for your kind attention. Thanks for the additional information. Unfortunately i am still unable to reproduce the problem. Does this happen for you with every file or only with some specific ones? Does anybody else see something similar? Despite this problem I will release current git HEAD as 0.5.1 sometime this weekend if no other show stopper bug (like a compile error ;) is found. Regards, Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dwm] [ANNOUNCE] dvtm-0.5
On Fri, 06 Feb 2009, Marc Andre Tanner wrote: Thanks for the additional information. Unfortunately i am still unable to reproduce the problem. Does this happen for you with every file or only with some specific ones? Does anybody else see something similar? I compiled and tested again and the problem was gone. How ever the initial extra ^Z persisted. -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 唐詩299 李商隱 寄令狐郎中 嵩雲秦樹久離居 雙鯉迢迢一紙筆 休問梁園舊賓客 茂陵秋雨病相如
Re: [dwm] [ANNOUNCE] dvtm-0.5
On Wed, Feb 04, 2009 at 10:35:48AM +0800, bill lam wrote: On Tue, 03 Feb 2009, Marc Andre Tanner wrote: This should now be fixed in current git HEAD. I will probably release dvtm-0.5.1 next weekend. Thanks for the report. I you have time, will you also test the screen redraw problem. When I use vim to edit two files and scroll up and down, it did not redraw properly. What do you mean exactly? I can't reproduce the redraw problem. Do you simply open a file with vim and then :split to edit another one? And after scrolling within vim with page-{up,down} something is wrong? Works here. Regards, Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dwm] [ANNOUNCE] dvtm-0.5
On Thu, Jan 29, 2009 at 03:44:06AM -0800, Donald Chai wrote: On Jan 29, 2009, at 12:49 AM, bill lam wrote: In commit sha1 a107d3 it added a call to an undeclared set_escdelay, and it fails to compile. Is that a known issue? You can replace that line with: ESCDELAY = esc_delay; This should now be fixed in current git HEAD. I will probably release dvtm-0.5.1 next weekend. Thanks for the report. By default, ncurses waits a long time to interpret escape sequences, which causes problems if you use vi and type faster than a snail, so this call reduces this delay. A more portable fix is to simply use the ESCDELAY environment variable when running dvtm: $ ESCDELAY=1 ./dvtm Regards, Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dwm] [ANNOUNCE] dvtm-0.5
On Tue, 03 Feb 2009, Marc Andre Tanner wrote: This should now be fixed in current git HEAD. I will probably release dvtm-0.5.1 next weekend. Thanks for the report. I you have time, will you also test the screen redraw problem. When I use vim to edit two files and scroll up and down, it did not redraw properly. -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 唐詩188 杜甫 宿府 清秋幕府井梧寒 獨宿江城蠟炬殘 永夜角聲悲自語 中天月色好誰看 風塵荏苒音書絕 關塞蕭條行陸難 已忍伶俜十年事 強移棲息一枝安
Re: [dwm] [ANNOUNCE] dvtm-0.5
On Jan 29, 2009, at 8:54 PM, bill lam wrote: On Thu, 29 Jan 2009, Donald Chai wrote: You can replace that line with: ESCDELAY = esc_delay; Thanks! I found 2 further issues 1. on my ubuntu, $TERM is xterm (actually it is 256 color), but dvtm cannot detect it and makes it a 8 (or 16?) color rxvt. You probably need to set TERM to xterm-256color. If 'infocmp xterm' says you have 8 colors, ncurses and dvtm will think your terminal only supports 8 colors. If you don't have the proper terminfo files, then be prepared for some fun with 'infocmp' and 'tic'. 2. if start dvtm from dmenu typing xterm -e dvtm there is always an extra ^Z placed in ttyin so that when I start to type any character, the ^Z appear and I have to delete it, However if I start dvtm from xterm, it is OK. Change config.mk to use ncursesw (LIBS_UTF8).
Re: [dwm] [ANNOUNCE] dvtm-0.5
On Fri, 30 Jan 2009, Donald Chai wrote: On Jan 29, 2009, at 8:54 PM, bill lam wrote: On Thu, 29 Jan 2009, Donald Chai wrote: You can replace that line with: ESCDELAY = esc_delay; Thanks! I found 2 further issues 1. on my ubuntu, $TERM is xterm (actually it is 256 color), but dvtm cannot detect it and makes it a 8 (or 16?) color rxvt. You probably need to set TERM to xterm-256color. If 'infocmp xterm' says you have 8 colors, ncurses and dvtm will think your terminal only supports 8 colors. If you don't have the proper terminfo files, then be prepared for some fun with 'infocmp' and 'tic'. After install terminfo for xterm-256color, echo $TERM inside xterm now gives xterm-256color, but after enter dvtm, echo $TERM now gives rxvt-256color, why not xterm-256color?. Moreover colors are displayed incorrectly. This is worse than using the previous xterm setting. 2. if start dvtm from dmenu typing xterm -e dvtm there is always an extra ^Z placed in ttyin so that when I start to type any character, the ^Z appear and I have to delete it, However if I start dvtm from xterm, it is OK. Change config.mk to use ncursesw (LIBS_UTF8). I already built with unicode $ldd dvtm linux-vdso.so.1 = (0x7fffa7ffe000) libc.so.6 = /lib/libc.so.6 (0x7f869f99c000) libutil.so.1 = /lib/libutil.so.1 (0x7f869f799000) libncursesw.so.5 = /lib/libncursesw.so.5 (0x7f869f552000) /lib64/ld-linux-x86-64.so.2 (0x7f869fd0e000) libdl.so.2 = /lib/libdl.so.2 (0x7f869f34e000) -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 唐詩303 李商隱 嫦娥 雲母屏風燭影深 長河漸落曉星沈 嫦娥應悔偷靈藥 碧海青天夜夜心
Re: [dwm] [ANNOUNCE] dvtm-0.5
On Jan 30, 2009, at 6:43 AM, bill lam wrote: On Fri, 30 Jan 2009, Donald Chai wrote: On Jan 29, 2009, at 8:54 PM, bill lam wrote: 1. on my ubuntu, $TERM is xterm (actually it is 256 color), but dvtm cannot detect it and makes it a 8 (or 16?) color rxvt. You probably need to set TERM to xterm-256color. If 'infocmp xterm' says you have 8 colors, ncurses and dvtm will think your terminal only supports 8 colors. If you don't have the proper terminfo files, then be prepared for some fun with 'infocmp' and 'tic'. After install terminfo for xterm-256color, echo $TERM inside xterm now gives xterm-256color, but after enter dvtm, echo $TERM now gives rxvt-256color, why not xterm-256color?. Moreover colors are displayed incorrectly. This is worse than using the previous xterm setting. So you mean that if you run the following shell command both outside and inside dvtm, you get different results? for i in `seq 1 64`; do echo -e \e[38;5;${i}mXXX; done The colors *should* match. If not, that's a bug. TERM is set to rxvt or rxvt-256color because those are the escape sequences interpreted by madtty.c. If you have code that absolutely must have TERM=xterm, I think it's sufficient to modify keytable in that file. 2. if start dvtm from dmenu typing xterm -e dvtm there is always an extra ^Z placed in ttyin so that when I start to type any character, the ^Z appear and I have to delete it, However if I start dvtm from xterm, it is OK. Change config.mk to use ncursesw (LIBS_UTF8). I already built with unicode $ldd dvtm linux-vdso.so.1 = (0x7fffa7ffe000) libc.so.6 = /lib/libc.so.6 (0x7f869f99c000) libutil.so.1 = /lib/libutil.so.1 (0x7f869f799000) libncursesw.so.5 = /lib/libncursesw.so.5 (0x7f869f552000) /lib64/ld-linux-x86-64.so.2 (0x7f869fd0e000) libdl.so.2 = /lib/libdl.so.2 (0x7f869f34e000) There seems to be some sort of race condition between SIGWINCH being raised and some other magic. I personally use rxvt-unicode (which works fine with urxvt -e dvtm) and only ever use dvtm on remote computers, so I'm not inclined to dig any deeper into this.
Re: [dwm] [ANNOUNCE] dvtm-0.5
The color test is ok. I found that it was vim that misinterpret the color, By coerce term to xterm, it's ok now. -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 唐詩217 李商隱 無題二首之一 鳳尾香羅薄幾重 碧文圓頂夜深縫 扇裁月魄羞難掩 車走雷聲語未通 曾是寂寥金燼暗 斷無消息石榴紅 斑騅只繫垂楊岸 何處西南任好風
Re: [dwm] [ANNOUNCE] dvtm-0.5
On Jan 29, 2009, at 12:49 AM, bill lam wrote: In commit sha1 a107d3 it added a call to an undeclared set_escdelay, and it fails to compile. Is that a known issue? You can replace that line with: ESCDELAY = esc_delay; By default, ncurses waits a long time to interpret escape sequences, which causes problems if you use vi and type faster than a snail, so this call reduces this delay. A more portable fix is to simply use the ESCDELAY environment variable when running dvtm: $ ESCDELAY=1 ./dvtm
Re: [dwm] [ANNOUNCE] dvtm-0.5
On Thu, 29 Jan 2009, Donald Chai wrote: You can replace that line with: ESCDELAY = esc_delay; Thanks! I found 2 further issues 1. on my ubuntu, $TERM is xterm (actually it is 256 color), but dvtm cannot detect it and makes it a 8 (or 16?) color rxvt. 2. if start dvtm from dmenu typing xterm -e dvtm there is always an extra ^Z placed in ttyin so that when I start to type any character, the ^Z appear and I have to delete it, However if I start dvtm from xterm, it is OK. -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 唐詩200 韓翃 同題仙游觀 仙臺初見五城樓 風物淒淒宿雨收 山色遙連秦樹晚 砧聲近報漢宮秋 疏松影落空壇靜 細草香閑小洞幽 何用別尋方外去 人間亦自有丹丘