Re: [dwm] [ANNOUNCE] dvtm-0.5

2009-02-08 Thread Marc Andre Tanner
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

2009-02-06 Thread Marc Andre Tanner
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

2009-02-06 Thread bill lam
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

2009-02-05 Thread Marc Andre Tanner
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

2009-02-03 Thread Marc Andre Tanner
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

2009-02-03 Thread bill lam
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

2009-01-30 Thread Donald Chai


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

2009-01-30 Thread bill lam
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

2009-01-30 Thread Donald Chai


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

2009-01-30 Thread bill lam
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

2009-01-29 Thread Donald Chai


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

2009-01-29 Thread bill lam
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 韓翃  同題仙游觀
仙臺初見五城樓  風物淒淒宿雨收  山色遙連秦樹晚  砧聲近報漢宮秋
疏松影落空壇靜  細草香閑小洞幽  何用別尋方外去  人間亦自有丹丘