mlterm-dev-en — mlterm mailing list(English)

Re: [Mlterm-dev-en] few question regarding mlterm initial configuration

[Araki K. <ara...@us...>]

 Hi,

From: Vladimir Elisseev <vo...@vo...>
Subject: Re: [Mlterm-dev-en] few question regarding mlterm initial configuration
Date: Sun, 11 Nov 2012 09:37:53 +0100
Message-ID: <135...@vo....home>

> Just compiled mlterm with your patch applied. However the pseudo
> graphics characters look exactly the same.

 Hmm, is -Y option specified in starting mlterm ?
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] few question regarding mlterm initial configuration

[Vladimir E. <vo...@vo...>]

Just compiled mlterm with your patch applied. However the pseudo
graphics characters look exactly the same.

Regards,
Vlad.

On Sun, 2012-11-11 at 17:17 +0900, Araki Ken wrote:
>  Hi,
> 
> From: Vladimir Elisseev <vo...@vo...>
> Subject: Re: [Mlterm-dev-en] few question regarding mlterm initial configuration
> Date: Sat, 10 Nov 2012 09:02:48 +0100
> Message-ID: <135...@vo....home>
> 
> > > > > > - While pseudo graphic characters displayed properly it the plain
> > > > > > terminal, they don't work as expected in tmux/screen
> > > > > 
> > > > >  Does it work on xterm with tmux/screen ?
> > > > >  I think tmux doesn't deal with graphic characters correctly.
> > > > > 
> > > > As I mentioned already, I've been using rxvt and pseudo graphics works
> > > > fine there with tmux/screen.
> > > 
> > >  Will you show me the screenshot of pseudo graphic characters which
> > > don't work as expected ?
> > 
> > see https://www.vovan.nl/files/mlterm_tmux.png
> > Note the bluish vertical lines, without tmux/screen they are white.
> >
> > >  (Is something like "qqqq" shown ? Or are lines drawn in incorrect positions ?)
> > > 
> > >  Then please tell me the version numbers of rxvt/tmux/screen,
> > 
> > screen - 4.00.03
> > tmux - 1.7
> > 
> > > and what is shown if you start mlterm without any configuration as follows.
> > > 
> > > $ mlterm -type xcore -km utf8 -ac 1 -e tmux -c "dialog --msgbox test 5 10"
> > 
> > the above works fine, but with non-antialiased font Terminus.
> 
>  I think this is because the unicode font you use doesn't contain line
> drawing characters (U+2500 etc).
> 
>  I attached a patch to improve such a situation.
>  Apply this patch to mlterm-3.1.5 and start mlterm with -Y option.
> 
>  Regards,
> ---
> Araki Ken
> ara...@us...
> plain text document attachment (mlterm-3.1.5post-fixdecspecial.patch)
> diff -r 689d086828ac main/main_loop.c
> --- a/main/main_loop.c	Tue Nov 06 20:30:18 2012 +0900
> +++ b/main/main_loop.c	Sun Nov 11 13:56:28 2012 +0900
> @@ -279,6 +279,7 @@
>  	{
>  		if( strcmp( value , "true") == 0)
>  		{
> +			ml_use_dec_special_font() ;
>  			x_compose_dec_special_font() ;
>  		}
>  	}
> diff -r 689d086828ac mlterm/ml_vt100_parser.c
> --- a/mlterm/ml_vt100_parser.c	Tue Nov 06 20:30:18 2012 +0900
> +++ b/mlterm/ml_vt100_parser.c	Sun Nov 11 13:56:28 2012 +0900
> @@ -87,9 +87,14 @@
>  #endif
>  
> 
> +/* --- static variables --- */
> +
> +static int  use_dec_special_font ;
> +
> +
>  /* --- static functions --- */
>  
> -/* XXX This function should be move to kiklib */
> +/* XXX This function should be moved to kiklib */
>  static void
>  str_replace(
>  	char *  str ,
> @@ -108,6 +113,88 @@
>  	}
>  }
>  
> +/* XXX This function should be moved to mkf */
> +u_char
> +convert_ucs_to_dec_special(
> +	u_int16_t  ucs
> +	)
> +{
> +	static struct
> +	{
> +		u_int16_t  ucs ;
> +		u_char  decsp ;
> +
> +	} ucs_to_decsp_table[] =
> +	{
> +		/* Not line characters */
> +	#if  0
> +		{ 0xa3 , '}' } ,
> +		{ 0xb0 , 'f' } ,
> +		{ 0xb1 , 'g' } ,
> +		{ 0xb7 , '~' } ,
> +		{ 0x3c0 , '{' } ,
> +		{ 0x2260 , '|' } ,
> +		{ 0x2264 , 'y' } ,
> +		{ 0x2265 , 'z' } ,
> +	#endif
> +
> +		/* Line characters */
> +		{ 0x23ba , 'o' } ,
> +		{ 0x23bb , 'p' } ,
> +		{ 0x23bc , 'r' } ,
> +		{ 0x23bd , 's' } ,
> +		{ 0x2500 , 'q' } ,
> +		{ 0x2502 , 'x' } ,
> +		{ 0x250c , 'l' } ,
> +		{ 0x2510 , 'k' } ,
> +		{ 0x2514 , 'm' } ,
> +		{ 0x2518 , 'j' } ,
> +		{ 0x251c , 't' } ,
> +		{ 0x2524 , 'u' } ,
> +		{ 0x252c , 'w' } ,
> +		{ 0x2534 , 'v' } ,
> +		{ 0x253c , 'n' } ,
> +
> +		{ 0x2592 , 'a' } ,
> +		{ 0x25c6 , '`' } ,
> +	} ;
> +	int  l_idx ;
> +	int  h_idx ;
> +	int  idx ;
> +
> +	l_idx = 0 ;
> +	h_idx = sizeof(ucs_to_decsp_table) / sizeof(ucs_to_decsp_table[0]) - 1 ;
> +
> +	if( ucs < ucs_to_decsp_table[l_idx].ucs ||
> +	    ucs_to_decsp_table[h_idx].ucs < ucs)
> +	{
> +		return  0 ;
> +	}
> +
> +	while( 1)
> +	{
> +		idx = (l_idx + h_idx) / 2 ;
> +
> +		if( ucs == ucs_to_decsp_table[idx].ucs)
> +		{
> +			return  ucs_to_decsp_table[idx].decsp ;
> +		}
> +		else if( ucs < ucs_to_decsp_table[idx].ucs)
> +		{
> +			h_idx = idx ;
> +		}
> +		else
> +		{
> +			l_idx = idx + 1 ;
> +		}
> +
> +		if( l_idx >= h_idx)
> +		{
> +			return  0 ;
> +		}
> +	}
> +}
> +
>  static void
>  start_vt100_cmd(
>  	ml_vt100_parser_t *  vt100_parser ,
> @@ -3929,6 +4016,8 @@
>  			 */
>  			if( ch.cs == ISO10646_UCS4_1)
>  			{
> +				u_char  decsp ;
> +
>  				if( ch.ch[0] == 0x00 && ch.ch[1] == 0x00 &&
>  					ch.ch[2] == 0x00 && ch.ch[3] <= 0x7f
>  					)
> @@ -3938,6 +4027,14 @@
>  					ch.size = 1 ;
>  					ch.cs = US_ASCII ;
>  				}
> +				else if( use_dec_special_font &&
> +				         ( decsp = convert_ucs_to_dec_special(
> +						mkf_bytes_to_int( ch.ch , ch.size))))
> +				{
> +					ch.ch[0] = decsp ;
> +					ch.size = 1 ;
> +					ch.cs = DEC_SPECIAL ;
> +				}
>  				else if( vt100_parser->unicode_policy & NOT_USE_UNICODE_FONT)
>  				{
>  					/* convert ucs4 to appropriate charset */
> @@ -4209,6 +4306,14 @@
>  
>  /* --- global functions --- */
>  
> +int
> +ml_use_dec_special_font(void)
> +{
> +	use_dec_special_font = 1 ;
> +
> +	return  1 ;
> +}
> +
>  ml_vt100_parser_t *
>  ml_vt100_parser_new(
>  	ml_screen_t *  screen ,

Re: [Mlterm-dev-en] few question regarding mlterm initial configuration

[Vladimir E. <vo...@vo...>]

Thanks! I'll try the patch, but I still can't understand why the same
font draws lines properly without screen/tmux?

Vlad.

On Sun, 2012-11-11 at 17:17 +0900, Araki Ken wrote:
>  Hi,
> 
> From: Vladimir Elisseev <vo...@vo...>
> Subject: Re: [Mlterm-dev-en] few question regarding mlterm initial configuration
> Date: Sat, 10 Nov 2012 09:02:48 +0100
> Message-ID: <135...@vo....home>
> 
> > > > > > - While pseudo graphic characters displayed properly it the plain
> > > > > > terminal, they don't work as expected in tmux/screen
> > > > > 
> > > > >  Does it work on xterm with tmux/screen ?
> > > > >  I think tmux doesn't deal with graphic characters correctly.
> > > > > 
> > > > As I mentioned already, I've been using rxvt and pseudo graphics works
> > > > fine there with tmux/screen.
> > > 
> > >  Will you show me the screenshot of pseudo graphic characters which
> > > don't work as expected ?
> > 
> > see https://www.vovan.nl/files/mlterm_tmux.png
> > Note the bluish vertical lines, without tmux/screen they are white.
> >
> > >  (Is something like "qqqq" shown ? Or are lines drawn in incorrect positions ?)
> > > 
> > >  Then please tell me the version numbers of rxvt/tmux/screen,
> > 
> > screen - 4.00.03
> > tmux - 1.7
> > 
> > > and what is shown if you start mlterm without any configuration as follows.
> > > 
> > > $ mlterm -type xcore -km utf8 -ac 1 -e tmux -c "dialog --msgbox test 5 10"
> > 
> > the above works fine, but with non-antialiased font Terminus.
> 
>  I think this is because the unicode font you use doesn't contain line
> drawing characters (U+2500 etc).
> 
>  I attached a patch to improve such a situation.
>  Apply this patch to mlterm-3.1.5 and start mlterm with -Y option.
> 
>  Regards,
> ---
> Araki Ken
> ara...@us...
> plain text document attachment (mlterm-3.1.5post-fixdecspecial.patch)
> diff -r 689d086828ac main/main_loop.c
> --- a/main/main_loop.c	Tue Nov 06 20:30:18 2012 +0900
> +++ b/main/main_loop.c	Sun Nov 11 13:56:28 2012 +0900
> @@ -279,6 +279,7 @@
>  	{
>  		if( strcmp( value , "true") == 0)
>  		{
> +			ml_use_dec_special_font() ;
>  			x_compose_dec_special_font() ;
>  		}
>  	}
> diff -r 689d086828ac mlterm/ml_vt100_parser.c
> --- a/mlterm/ml_vt100_parser.c	Tue Nov 06 20:30:18 2012 +0900
> +++ b/mlterm/ml_vt100_parser.c	Sun Nov 11 13:56:28 2012 +0900
> @@ -87,9 +87,14 @@
>  #endif
>  
> 
> +/* --- static variables --- */
> +
> +static int  use_dec_special_font ;
> +
> +
>  /* --- static functions --- */
>  
> -/* XXX This function should be move to kiklib */
> +/* XXX This function should be moved to kiklib */
>  static void
>  str_replace(
>  	char *  str ,
> @@ -108,6 +113,88 @@
>  	}
>  }
>  
> +/* XXX This function should be moved to mkf */
> +u_char
> +convert_ucs_to_dec_special(
> +	u_int16_t  ucs
> +	)
> +{
> +	static struct
> +	{
> +		u_int16_t  ucs ;
> +		u_char  decsp ;
> +
> +	} ucs_to_decsp_table[] =
> +	{
> +		/* Not line characters */
> +	#if  0
> +		{ 0xa3 , '}' } ,
> +		{ 0xb0 , 'f' } ,
> +		{ 0xb1 , 'g' } ,
> +		{ 0xb7 , '~' } ,
> +		{ 0x3c0 , '{' } ,
> +		{ 0x2260 , '|' } ,
> +		{ 0x2264 , 'y' } ,
> +		{ 0x2265 , 'z' } ,
> +	#endif
> +
> +		/* Line characters */
> +		{ 0x23ba , 'o' } ,
> +		{ 0x23bb , 'p' } ,
> +		{ 0x23bc , 'r' } ,
> +		{ 0x23bd , 's' } ,
> +		{ 0x2500 , 'q' } ,
> +		{ 0x2502 , 'x' } ,
> +		{ 0x250c , 'l' } ,
> +		{ 0x2510 , 'k' } ,
> +		{ 0x2514 , 'm' } ,
> +		{ 0x2518 , 'j' } ,
> +		{ 0x251c , 't' } ,
> +		{ 0x2524 , 'u' } ,
> +		{ 0x252c , 'w' } ,
> +		{ 0x2534 , 'v' } ,
> +		{ 0x253c , 'n' } ,
> +
> +		{ 0x2592 , 'a' } ,
> +		{ 0x25c6 , '`' } ,
> +	} ;
> +	int  l_idx ;
> +	int  h_idx ;
> +	int  idx ;
> +
> +	l_idx = 0 ;
> +	h_idx = sizeof(ucs_to_decsp_table) / sizeof(ucs_to_decsp_table[0]) - 1 ;
> +
> +	if( ucs < ucs_to_decsp_table[l_idx].ucs ||
> +	    ucs_to_decsp_table[h_idx].ucs < ucs)
> +	{
> +		return  0 ;
> +	}
> +
> +	while( 1)
> +	{
> +		idx = (l_idx + h_idx) / 2 ;
> +
> +		if( ucs == ucs_to_decsp_table[idx].ucs)
> +		{
> +			return  ucs_to_decsp_table[idx].decsp ;
> +		}
> +		else if( ucs < ucs_to_decsp_table[idx].ucs)
> +		{
> +			h_idx = idx ;
> +		}
> +		else
> +		{
> +			l_idx = idx + 1 ;
> +		}
> +
> +		if( l_idx >= h_idx)
> +		{
> +			return  0 ;
> +		}
> +	}
> +}
> +
>  static void
>  start_vt100_cmd(
>  	ml_vt100_parser_t *  vt100_parser ,
> @@ -3929,6 +4016,8 @@
>  			 */
>  			if( ch.cs == ISO10646_UCS4_1)
>  			{
> +				u_char  decsp ;
> +
>  				if( ch.ch[0] == 0x00 && ch.ch[1] == 0x00 &&
>  					ch.ch[2] == 0x00 && ch.ch[3] <= 0x7f
>  					)
> @@ -3938,6 +4027,14 @@
>  					ch.size = 1 ;
>  					ch.cs = US_ASCII ;
>  				}
> +				else if( use_dec_special_font &&
> +				         ( decsp = convert_ucs_to_dec_special(
> +						mkf_bytes_to_int( ch.ch , ch.size))))
> +				{
> +					ch.ch[0] = decsp ;
> +					ch.size = 1 ;
> +					ch.cs = DEC_SPECIAL ;
> +				}
>  				else if( vt100_parser->unicode_policy & NOT_USE_UNICODE_FONT)
>  				{
>  					/* convert ucs4 to appropriate charset */
> @@ -4209,6 +4306,14 @@
>  
>  /* --- global functions --- */
>  
> +int
> +ml_use_dec_special_font(void)
> +{
> +	use_dec_special_font = 1 ;
> +
> +	return  1 ;
> +}
> +
>  ml_vt100_parser_t *
>  ml_vt100_parser_new(
>  	ml_screen_t *  screen ,

Re: [Mlterm-dev-en] few question regarding mlterm initial configuration

[Araki K. <ara...@us...>]

 Hi,

From: Vladimir Elisseev <vo...@vo...>
Subject: Re: [Mlterm-dev-en] few question regarding mlterm initial configuration
Date: Sat, 10 Nov 2012 09:02:48 +0100
Message-ID: <135...@vo....home>

> > > > > - While pseudo graphic characters displayed properly it the plain
> > > > > terminal, they don't work as expected in tmux/screen
> > > > 
> > > >  Does it work on xterm with tmux/screen ?
> > > >  I think tmux doesn't deal with graphic characters correctly.
> > > > 
> > > As I mentioned already, I've been using rxvt and pseudo graphics works
> > > fine there with tmux/screen.
> > 
> >  Will you show me the screenshot of pseudo graphic characters which
> > don't work as expected ?
> 
> see https://www.vovan.nl/files/mlterm_tmux.png
> Note the bluish vertical lines, without tmux/screen they are white.
>
> >  (Is something like "qqqq" shown ? Or are lines drawn in incorrect positions ?)
> > 
> >  Then please tell me the version numbers of rxvt/tmux/screen,
> 
> screen - 4.00.03
> tmux - 1.7
> 
> > and what is shown if you start mlterm without any configuration as follows.
> > 
> > $ mlterm -type xcore -km utf8 -ac 1 -e tmux -c "dialog --msgbox test 5 10"
> 
> the above works fine, but with non-antialiased font Terminus.

 I think this is because the unicode font you use doesn't contain line
drawing characters (U+2500 etc).

 I attached a patch to improve such a situation.
 Apply this patch to mlterm-3.1.5 and start mlterm with -Y option.

 Regards,
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] few question regarding mlterm initial configuration

[Vladimir E. <vo...@vo...>]

Thanks for your answer! See my comments in-line below.

Regards,
Vlad.

On Sat, 2012-11-10 at 06:36 +0900, Araki Ken wrote:
>  Hi,
> 
> From: Vladimir Elisseev <vo...@vo...>
> Subject: Re: [Mlterm-dev-en] few question regarding mlterm initial configuration
> Date: Fri, 02 Nov 2012 06:28:33 +0100
> Message-ID: <135...@vo....home>
> 
> > Initially I've user TERM=mlterm-256color where Home/End keys waren't
> > working, but if I use TERM=rxvt-unicode-256color, at least Home/End keys
> > are working properly. Nevertheless, I don't understand why (khome is the
> > same for both terminals):
> > 
> > infocmp rxvt-unicode-256color | grep home
> >         home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
> >         kf8=\E[19~, kf9=\E[20~, kfnd=\E[1~, khome=\E[7~,
> > 
> > infocmp mlterm-256color | grep home
> >         enacs=\E(B\E)0, flash=\E[?5h\E[?5l, home=\E[H,
> >         khome=\E[7~, kich1=\E[2~, kind=\E[a, kmous=\E[M, knp=\E[6~,
> 
>  I'm sorry but I can't understand why Home/End keys work in
> TERM=rxvt-unicode-256color and doesn't work in TERM=mlterm-256color.
> 
>  Do you use Home/End keys in the shell (bash ? zsh?) or some
> other applications ?

Home/End keys work fine in bash/sh with TERM=mlterm-256color, for zsh I
had fix for rxvt already, so I have to add similar for mlterm:
case $TERM in (rxvt*)
        bindkey '^[[7~' beginning-of-line
        bindkey '^[[8~' end-of-line
esac
case $TERM in (mlterm*)
        bindkey '^[OH' beginning-of-line
        bindkey '^[OF' end-of-line
esac


>  BTW, khome=\E7~ in "mlterm-256color" terminfo is wrong.
>  mlterm outputs \EOH for khome by default.
>  This doesn't seem to be the reason why Home/End keys doesn't work, though.
> 
> > > > - While pseudo graphic characters displayed properly it the plain
> > > > terminal, they don't work as expected in tmux/screen
> > > 
> > >  Does it work on xterm with tmux/screen ?
> > >  I think tmux doesn't deal with graphic characters correctly.
> > > 
> > As I mentioned already, I've been using rxvt and pseudo graphics works
> > fine there with tmux/screen.
> 
>  Will you show me the screenshot of pseudo graphic characters which
> don't work as expected ?

see https://www.vovan.nl/files/mlterm_tmux.png Note the bluish vertical lines, without tmux/screen they are white.

>  (Is something like "qqqq" shown ? Or are lines drawn in incorrect positions ?)
> 
>  Then please tell me the version numbers of rxvt/tmux/screen,

screen - 4.00.03
tmux - 1.7

> and what is shown if you start mlterm without any configuration as follows.
> 
> $ mlterm -type xcore -km utf8 -ac 1 -e tmux -c "dialog --msgbox test 5 10"

the above works fine, but with non-antialiased font Terminus.

> 
> > > > - How to make 265 colors working properly? I've adjusted the colors
> > > > file, so it includes all the colorXXX=#XXXXXX lines and tried to use
> > > > TERM with mlterm-256colors/xterm-256colors, but unsuccessfully...
> > > 
> > >  256 colors are supprted without any configuration of ~/.mlterm/color.
> > >  Does http://frexx.de/xterm-256-notes/data/256colors2.pl work ?
> > > 
> > This script works perfectly fine. While base color definitions in
> > ~/.mlterm/color works fine, if I define additional colors there like
> > "color25=#005faf" they are not picked up.
> 
>  If you want to define 256 colors manually, define ~/.mlterm/color as follows.
> 
> 25 = #005faf

Thanks for this. This is not clear from the manual page of mlterm what
is the right names of colors. Though now all colors work they are a bit
different then in urxvt. 

> 
>  Regards,
> ---
> Araki Ken
> ara...@us...

Re: [Mlterm-dev-en] A few glitches.

[Andi C. S. <ski...@ya...>]

Hello and thanks,

> pts_0-linux.log, pts-0_xterm.log, pts-0_mlterm.log contains

> "\x1b[30m" which makes foreground color black and immediately following
> "\x1b[40m" which makes background color black.
>
> I think this problem isn't caused by mlterm but by the configuration
> of mutt.
>
> How about adding a following line to ~/.muttrc
>
> color normal default default


You were right; it was mutt. Even though no colours were specified, it
chose black on black for some reason. NVLC probably has the same
problem, but I can't verify it because the colour scheme can't be
changed. I'll try to talk with the people who maintain them.
 
> How do you change the cursor color ?
> Doesn't a following command work ?
>
> echo -e "\x1b]12;red\x07"


Yes, it does make it (dark) red. I don't normally change it, though; I
use the default (which is reverse-video) plus blink.

Since the TERM values better supported by applications such as linux
and xterm require bce, I have to append ut to their entries in
./mlterm/termcap, otherwise coloured areas don't fill as they should.
Doing so, however, will trigger the aforementioned coloured cursor
glitch.
> Indeed it is possible to ignore color sequences (ESC [ m) except black
> and white, but is it necessary to support a monochrome terminal ?
> Furthermore I think the binary won't be smaller than expected.


Actually, I think xterm's colorMode: 0 disregards all colour sequences,
including black and white. Since there's only one colour anyway (+ RV),
there's no need for them anymore, and they might also mess up some
things, so that's the way I think it should be done. It may or may not
disable other things like colour for attributes, cursor colour and so
on (I don't remember exactly how it works), but that's not important.

If there's no benefit to disabling colour at compile-time, then of
course there's no reason to do it. An option to ignore colour escapes,
however, would help in eliminating the coloured output that some apps
(mostly non-curses) output gratuitously, regardless of what TERM is.

Since I started fiddling around with those terminfos, I have (for one)
found out that plain monochrome (plus the various attributes) is very
pleasant, yet can still convey sufficient information. Removing the
distraction of coloured text in this case is, ultimately, a matter of
personal preference. Others may not like it (or may not care), but I
still think It's a good thing to have, at least for customisation's sake.
Regards,

Andi Șerbănescu

Re: [Mlterm-dev-en] few question regarding mlterm initial configuration

[Araki K. <ara...@us...>]

 Hi,

From: Vladimir Elisseev <vo...@vo...>
Subject: Re: [Mlterm-dev-en] few question regarding mlterm initial configuration
Date: Fri, 02 Nov 2012 06:28:33 +0100
Message-ID: <135...@vo....home>

> Initially I've user TERM=mlterm-256color where Home/End keys waren't
> working, but if I use TERM=rxvt-unicode-256color, at least Home/End keys
> are working properly. Nevertheless, I don't understand why (khome is the
> same for both terminals):
> 
> infocmp rxvt-unicode-256color | grep home
>         home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
>         kf8=\E[19~, kf9=\E[20~, kfnd=\E[1~, khome=\E[7~,
> 
> infocmp mlterm-256color | grep home
>         enacs=\E(B\E)0, flash=\E[?5h\E[?5l, home=\E[H,
>         khome=\E[7~, kich1=\E[2~, kind=\E[a, kmous=\E[M, knp=\E[6~,

 I'm sorry but I can't understand why Home/End keys work in
TERM=rxvt-unicode-256color and doesn't work in TERM=mlterm-256color.

 Do you use Home/End keys in the shell (bash ? zsh?) or some
other applications ?

 BTW, khome=\E7~ in "mlterm-256color" terminfo is wrong.
 mlterm outputs \EOH for khome by default.
 This doesn't seem to be the reason why Home/End keys doesn't work, though.

> > > - While pseudo graphic characters displayed properly it the plain
> > > terminal, they don't work as expected in tmux/screen
> > 
> >  Does it work on xterm with tmux/screen ?
> >  I think tmux doesn't deal with graphic characters correctly.
> > 
> As I mentioned already, I've been using rxvt and pseudo graphics works
> fine there with tmux/screen.

 Will you show me the screenshot of pseudo graphic characters which
don't work as expected ?
 (Is something like "qqqq" shown ? Or are lines drawn in incorrect positions ?)

 Then please tell me the version numbers of rxvt/tmux/screen,
and what is shown if you start mlterm without any configuration as follows.

$ mlterm -type xcore -km utf8 -ac 1 -e tmux -c "dialog --msgbox test 5 10"

> > > - How to make 265 colors working properly? I've adjusted the colors
> > > file, so it includes all the colorXXX=#XXXXXX lines and tried to use
> > > TERM with mlterm-256colors/xterm-256colors, but unsuccessfully...
> > 
> >  256 colors are supprted without any configuration of ~/.mlterm/color.
> >  Does http://frexx.de/xterm-256-notes/data/256colors2.pl work ?
> > 
> This script works perfectly fine. While base color definitions in
> ~/.mlterm/color works fine, if I define additional colors there like
> "color25=#005faf" they are not picked up.

 If you want to define 256 colors manually, define ~/.mlterm/color as follows.

25 = #005faf

 Regards,
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] A few glitches.

[Araki K. <ara...@us...>]

 Hi,

From: Andi Cristian Serbanescu <ski...@ya...>
Subject: Re: [Mlterm-dev-en] A few glitches.
Date: Thu, 1 Nov 2012 10:55:52 -0700 (PDT)
Message-ID: <135...@we...>

> > I tried mutt 1.5.21 on Ubuntu 12.04 but couldn't reproduce this problem.
> > I'm sorry but I don't have enough information to reproduce it.
> > 
> > Please start mlterm with --logseq option and send me a ~/.mlterm/*.log
> > file after the problem happens.
> 
> I've put the pty logs in the .tar.gz file, under a folder called log. I
> didn't get any message logs. The problem happens right away.
> It may have something to do with the colour escapes, since it works
> with monochrome terminfos (e.g. vt220, linux-m etc.). I've included some
> for comparison.

 pts_0-linux.log, pts-0_xterm.log, pts-0_mlterm.log contains
"\x1b[30m" which makes foreground color black and immediately following
"\x1b[40m" which makes background color black.

 I think this problem isn't caused by mlterm but by the configuration
of mutt.

 How about adding a following line to ~/.muttrc

color normal default default


> > I think it is derived from doc/term/mlterm.ti in mlterm source archives,
> > but the mlterm terminfo file in ncurses is maintained by the ncurses people.
> 
> I checked it and it's almost identical to the one bundled with the
> source code (it has a few extra keys). There's also mlterm-256color,
> which is based on rxvt.
> 
> It assigns \EOA to the arrow keys, although the terminal outputs \E[A.
> One program (finch) doesn't like the arrow keys this way. If I change
> them to what is output, then finch works, but others (e.g. less) don't.
> 
> Many programs seem to work better with linux than with mlterm or even
> xterm.
> 
> Because of this, it would still be nice if .mlterm/termcap would accept
> a k5 option, thus eliminating the need for having a .mlterm/key file
> with only one entry :)

 I added k5 in mlterm 3.1.5.

> Of course, there's still the coloured cursor thing. Are you sure it's
> not fixable some other way?

 How do you change the cursor color ?
 Doesn't a following command work ?

echo -e "\x1b]12;red\x07"

> > I have a plan to support the former opinion, but I haven't implement anything yet.
> > About the latter one, it is quite difficult to support the ability to highlight
> > the full row in addition to the default behavior.
> 
> What about instead of the default behaviour? Is there any reason it
> should be preferred?

 At first I designed and implemented the text selection behavior
like notepad.exe instead of xterm because of my preference.
 As a result, the internal implementation of layouting characters
depends heavily on this bahavior now.
 I'm sorry but a range of corrections is too extensive to change the
default bahavior.

> And by the way, how about one to disable colours at run-time (and maybe
> even at build-time, so that the binary would be smaller) entirely so we
> could get a monochrome terminal?
> Some things still output colour even if a monochrome terminfo is used,
> so an option to ignore colour codes would be needed for this.

 Indeed it is possible to ignore color sequences (ESC [ m) except black
and white, but is it necessary to support a monochrome terminal ?
 Furthermore I think the binary won't be smaller than expected.

 Regards,
---
Araki Ken
ara...@us...

[Mlterm-dev-en] mlterm 3.1.5 released

[Araki K. <ara...@us...>]

 Hi,
  
 This is to announce the release of mlterm version 3.1.4
  
http://sourceforge.net/projects/mlterm/files/01release/mlterm-3.1.4/mlterm-3.1.4.tar.gz/download

MD5 (mlterm-3.1.5.tar.gz) = bf95f725cb6521f1861abc8dd3326d5a
SHA1 (mlterm-3.1.5.tar.gz) = d5031d0e4b9c4afa9a3c77ec99e7089253745171
  
Overview of changes from 3.1.4
===============================  
ver 3.1.5
* Support framebuffer on Linux. (Experimental)
  (See doc/en/README.fb or doc/ja/README.fb in detail.)
* Support "?" of OSC 4, 10 and 11.
* Support CSI 14 t and CSI 18 t.
* Break the binary compatility of extra scrollbars and pixmap_engine
  with the ones before 3.1.4.
* Add "update_all" to the configuration protocol.
* Add k5 entry for ~/.mlterm/termcap.
* Bug fixes:
  Fix the incomplete hebavior of double- or triple-clicking and dragging.
  (Thanks to Andi Cristian Serbanescu)

--
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] few question regarding mlterm initial configuration

[Vladimir E. <vo...@vo...>]

Araki,

Thanks for your replay as it's hard to find information in English
regarding mlterm. See my comments in-line below.

Regards,
Vlad.

On Fri, 2012-11-02 at 06:58 +0900, Araki Ken wrote:
>  Hi,
> 
> From: Vladimir Elisseev <vo...@vo...>
> Subject: [Mlterm-dev-en] few question regarding mlterm initial configuration
> Date: Tue, 30 Oct 2012 09:25:20 +0100
> Message-ID: <135...@vo....home>
> 
> > - Home/End keys and well as some Ctrl+Fx keys aren't working (I've tried
> > to adjust termcap, but can't find the proper key codes)
> 
>  If the value of TERM environmental variable is xterm and infocmp returns
> as follows
> 
> $ infocmp xterm | grep khome
> khome = \EOH
> 
> , how about adding a following option to ~/.mlterm/termcap ?
> 
> xterm:\
> 	kh=\EOH
> 
Initially I've user TERM=mlterm-256color where Home/End keys waren't
working, but if I use TERM=rxvt-unicode-256color, at least Home/End keys
are working properly. Nevertheless, I don't understand why (khome is the
same for both terminals):

infocmp rxvt-unicode-256color | grep home
        home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
        kf8=\E[19~, kf9=\E[20~, kfnd=\E[1~, khome=\E[7~,

infocmp mlterm-256color | grep home
        enacs=\E(B\E)0, flash=\E[?5h\E[?5l, home=\E[H,
        khome=\E[7~, kich1=\E[2~, kind=\E[a, kmous=\E[M, knp=\E[6~,

>  Control+F1 ... Control+F4 combinations are assigned to shortcut keys
> by default.
>  If you want to disable these short cut keys, add following lines to
> ~/.mlterm/key.
> 
> Control+F1=UNUSED
> Control+F2=UNUSED
> Control+F3=UNUSED
> Control+F4=UNUSED
> 
This was exactly the reason! I didn't try to reassign these keys, but
when I've tried to open new tty using corresponding key combination it
doesn't work.

> > - While pseudo graphic characters displayed properly it the plain
> > terminal, they don't work as expected in tmux/screen
> 
>  Does it work on xterm with tmux/screen ?
>  I think tmux doesn't deal with graphic characters correctly.
> 
As I mentioned already, I've been using rxvt and pseudo graphics works
fine there with tmux/screen.  

> > - How to make 265 colors working properly? I've adjusted the colors
> > file, so it includes all the colorXXX=#XXXXXX lines and tried to use
> > TERM with mlterm-256colors/xterm-256colors, but unsuccessfully...
> 
>  256 colors are supprted without any configuration of ~/.mlterm/color.
>  Does http://frexx.de/xterm-256-notes/data/256colors2.pl work ?
> 
This script works perfectly fine. While base color definitions in
~/.mlterm/color works fine, if I define additional colors there like
"color25=#005faf" they are not picked up.

>  BTW, does "xterm-256colors" exist in terminfo ?
>  (Whether it exists or not can be tested by "infocmp xterm-256colors".)
> 
>  How about using TERM with "xterm-256color" ?
> 
>  Regards,
> ---
> Araki Ken
> ara...@us...

Re: [Mlterm-dev-en] few question regarding mlterm initial configuration

[Araki K. <ara...@us...>]

 Hi,

From: Vladimir Elisseev <vo...@vo...>
Subject: [Mlterm-dev-en] few question regarding mlterm initial configuration
Date: Tue, 30 Oct 2012 09:25:20 +0100
Message-ID: <135...@vo....home>

> - Home/End keys and well as some Ctrl+Fx keys aren't working (I've tried
> to adjust termcap, but can't find the proper key codes)

 If the value of TERM environmental variable is xterm and infocmp returns
as follows

$ infocmp xterm | grep khome
khome = \EOH

, how about adding a following option to ~/.mlterm/termcap ?

xterm:\
	kh=\EOH

 Control+F1 ... Control+F4 combinations are assigned to shortcut keys
by default.
 If you want to disable these short cut keys, add following lines to
~/.mlterm/key.

Control+F1=UNUSED
Control+F2=UNUSED
Control+F3=UNUSED
Control+F4=UNUSED

> - While pseudo graphic characters displayed properly it the plain
> terminal, they don't work as expected in tmux/screen

 Does it work on xterm with tmux/screen ?
 I think tmux doesn't deal with graphic characters correctly.

> - How to make 265 colors working properly? I've adjusted the colors
> file, so it includes all the colorXXX=#XXXXXX lines and tried to use
> TERM with mlterm-256colors/xterm-256colors, but unsuccessfully...

 256 colors are supprted without any configuration of ~/.mlterm/color.
 Does http://frexx.de/xterm-256-notes/data/256colors2.pl work ?

 BTW, does "xterm-256colors" exist in terminfo ?
 (Whether it exists or not can be tested by "infocmp xterm-256colors".)

 How about using TERM with "xterm-256color" ?

 Regards,
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] A few glitches.

[Andi C. S. <ski...@ya...>]

Hello,

Thank you for your response.

> I think this behavior follows that of xterm.
> For example, if Shift+Delete which is not assigned as any shortcut key
> is pressed, mlterm exits back-scrolling mode and outputs "\x1b[3;2~"
> ("\x1b[3" means DEL key and ";2~" means combination with shift key)
> to the pty. As a result, "2~" which is not parsed by the shell is shown.
> I think it is a normal behavior.

I think you're right. This should be handled at application-level.

> I tried mutt 1.5.21 on Ubuntu 12.04 but couldn't reproduce this problem.
> I'm sorry but I don't have enough information to reproduce it.
> 
> Please start mlterm with --logseq option and send me a ~/.mlterm/*.log
> file after the problem happens.

I've put the pty logs in the .tar.gz file, under a folder called log. I
didn't get any message logs. The problem happens right away.

It may have something to do with the colour escapes, since it works
with monochrome terminfos (e.g. vt220, linux-m etc.). I've included some
for comparison.

> I think it is derived from doc/term/mlterm.ti in mlterm source archives,
> but the mlterm terminfo file in ncurses is maintained by the ncurses people.

I checked it and it's almost identical to the one bundled with the
source code (it has a few extra keys). There's also mlterm-256color,
which is based on rxvt.

It assigns \EOA to the arrow keys, although the terminal outputs \E[A.
One program (finch) doesn't like the arrow keys this way. If I change
them to what is output, then finch works, but others (e.g. less) don't.

Many programs seem to work better with linux than with mlterm or even
xterm.

Because of this, it would still be nice if .mlterm/termcap would accept
a k5 option, thus eliminating the need for having a .mlterm/key file
with only one entry :)

Of course, there's still the coloured cursor thing. Are you sure it's
not fixable some other way?

> I have a plan to support the former opinion, but I haven't implement anything yet.
> About the latter one, it is quite difficult to support the ability to highlight
> the full row in addition to the default behavior.

What about instead of the default behaviour? Is there any reason it
should be preferred?

And by the way, how about one to disable colours at run-time (and maybe
even at build-time, so that the binary would be smaller) entirely so we
could get a monochrome terminal?

Some things still output colour even if a monochrome terminfo is used,
so an option to ignore colour codes would be needed for this.

Regards,
Andi Șerbănescu

[Mlterm-dev-en] few question regarding mlterm initial configuration

[Vladimir E. <vo...@vo...>]

Hello,

I have been rxvt-uninode user for quite a while, but recently I've
decided to move to mlterm.  While rxvt eats memory like crazy, mlterm in
the same situation uses 10 times less ;-). It's always takes a while to
make initial configuration, so the same story with mlterm. It works
perfectly fine but I have a few questions regarding adjusting some
configuration parameters, so below they are:
- Home/End keys and well as some Ctrl+Fx keys aren't working (I've tried
to adjust termcap, but can't find the proper key codes)
- While pseudo graphic characters displayed properly it the plain
terminal, they don't work as expected in tmux/screen
- How to make 265 colors working properly? I've adjusted the colors
file, so it includes all the colorXXX=#XXXXXX lines and tried to use
TERM with mlterm-256colors/xterm-256colors, but unsuccessfully...

I'd appreciate any help or links to the useful info about the
configuration questions above.

Regards,
Vlad.

Re: [Mlterm-dev-en] A few glitches.

[Araki K. <ara...@us...>]

 Hi ,

From: Andi Cristian Serbanescu <ski...@ya...>
Subject: Re: [Mlterm-dev-en] A few glitches.
Date: Wed, 24 Oct 2012 08:30:36 -0700 (PDT)
Message-ID: <135...@we...>

> > > 3. Double- and triple-click select one word/line at a
> > > time. However, double- and triple-clicking and then
> > > dragging the pointer will revert back to selecting
> > > one character at a time.
> > 
> >  As you mentioned, this behavior is not compatible with
> > xterm, but it is
> > not easy to solve. It will take some time to think of the
> > way to modify
> > source code.
> 
> As of 3.1.4, I see that it no longer deselects what has already been highlighted,
> but any further selection will still be on a one-character-at-a-time basis.

 Thanks. I fixed this remaining problem.

> > > 4. Shift + PgDn (which scrolls down one screen) will output 2~
> > > once it reaches ethe bottom. Shift + some other keys (Home, End,
> > > Delete, Left, Up, Down, Right and maybe others) also display stuff,
> > > even though they don't do anything.
> > 
> >  The attached patch fixes this problem.
> 
> It's gone for Shift+PgUp/Dn, but it remains for other key combinations
> (Shift/Alt/Control+KEY).

 I think this behavior follows that of xterm.
 For example, if Shift+Delete which is not assigned as any shortcut key
is pressed, mlterm exits back-scrolling mode and outputs "\x1b[3;2~"
("\x1b[3" means DEL key and ";2~" means combination with shift key)
to the pty. As a result, "2~" which is not parsed by the shell is shown.
 I think it is a normal behavior.

> > > 5. Some programs, such as mutt and nvlc (the ncurses interface for vlc)
> > > will display black text on black background instead of white on black
> > > (or whatever else you set fg/bg to). This one also happens with xterm
> > > and urxvt as far as I know.
> >  I haven't test mutt and nlvc yet, sorry.
> 
> Could you please look into it when you will have time?

 I tried mutt 1.5.21 on Ubuntu 12.04 but couldn't reproduce this problem.
 I'm sorry but I don't have enough information to reproduce it.

 Please start mlterm with --logseq option and send me a ~/.mlterm/*.log
file after the problem happens.

> > > 6. I personally prefer to use the linux terminfo entry with mlterm, but
> > > it expects keys F1 to F5 to output something else than mlterm does, and
> > > there's no way to change it (e.g. via ~/.mlterm/termcap).
> > 
> >  How about following settings in ~/.mlterm/key ?
> > 
> > F1="\x1bOP"
> > F2="\x1bOQ"
> > F3="\x1bOR"
> > F4="\x1bOS"
> 
> I overlooked that :) They do work (actually only the first four function
> keys can be reassigned via termcap), although it's pretty cumbersome,
> because termcap is still better for the others (e.g. reassigning BkSp to
> ^? via termcap will also work for its combinations).
> 
> The mlterm terminfo file that comes with ncurses solves the key mapping
> stuff and the coloured cursor, but it has its own flaws.
> Did you write it, or is it the work of the ncurses people?

 I think it is derived from doc/term/mlterm.ti in mlterm source archives,
but the mlterm terminfo file in ncurses is maintained by the ncurses people.

> PS. What would be your opinion on 2 new features: an option to choose the mouse pointer and the ability to highlight the full row with the mouse when selecting the newline character?

 I have a plan to support the former opinion, but I haven't implement anything yet.
 About the latter one, it is quite difficult to support the ability to highlight
the full row in addition to the default behavior.

 Regards,
---
Araki Ken
ara...@us...

[Mlterm-dev-en] mlterm 3.1.4 released

[Araki K. <ara...@us...>]

 Hi,
 
 This is to announce the release of mlterm version 3.1.4
 
http://sourceforge.net/projects/mlterm/files/01release/mlterm-3.1.4/mlterm-3.1.4.tar.gz/download

MD5 (mlterm-3.1.4.tar.gz) = eeb049b1ba6e3713918936db428103c7
SHA1 (mlterm-3.1.4.tar.gz) = 12411fe8dc59969a2b74cc01bcd4cfe5316c0a43
 
Overview of changes from 3.1.3
===============================
 
ver 3.1.4
* Support 0x90...0x9c format for sixel graphics sequence.
* Change the file where sixel graphics sequence is stored temporarily
  from ~/.mlterm/picture.six to ~/.mlterm/[tty name].six.
* Add k1, k2, k3 and k4 entries for ~/.mlterm/termcap.
* Change key sequences in term_type=xterm.
  XK_F1:     \x1b[11~ -> \x1bOP
  XK_F2:     \x1b[12~ -> \x1bOQ
  XK_F3:     \x1b[13~ -> \x1bOR
  XK_F4:     \x1b[14~ -> \x1bOS
* Support remote image files via network protocols supported by GVfs.
  (e.g. mlterm -pic http://....)
* Use CSI ? 8428 instead of CSI ? 8840. (Thanks to saitoha san)
* Bug fixes:
  Fix conflicting types of kik_utmp_new. (Thanks to KATO Masashi san)
  Erase wrap line attributes completely in clearing lines.
  (Thanks to Andi Cristian Serbanescu)
  Enable PAGE_DOWN shortcut (which doesn't anything) when it reaches the bottom.
  (Thanks to Andi Cristian Serbanescu)
  Fix freeze in scrolling by CSI r. (Thanks to koie san)
  Fix the problem which always replaces the 2nd or later sixel graphics with
  the 1st one if mlterm is compiled with --with-imagelib=gdk-pixbuf option.
  (Thanks to saitoha asn)
  Fix the problem of reverting back to selecting one character at a time
  by dragging the pointer after double- or triple-clicking.
  (Thanks to Andi Cristian Serbanescu)
--
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] A few glitches.

[Araki K. <ara...@us...>]

 Thanks for your detailed report.

From: Andi Cristian Serbanescu <ski...@ya...>
Subject: [Mlterm-dev-en] A few glitches.
Date: Thu, 30 Aug 2012 06:23:49 -0700 (PDT)
Message-ID: <134...@we...>

> 1. After some text is output which is too long to fit in one line and
> then clearing the screen, the lines which were wraped around can still
> be selected with the mouse. Can be tested e.g. by typing random strings
> or by issuing ls -l in a directory with some long file names.

 The attached patch fixes this problem.

> 2. (May be related) Happens with some fancy shell prompts, if the path
> is part of the prompt, or the prompt itself is too long: a coloured
> prompt too long to fit in one line will also colour the cursor. May be
> tested (with bash) by setting the prompt to:
> 
> PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[00m\] '
> 
> Sometimes you have to trigger behaviour 1 in order to activate 2.

 Indeed it looks strange, but xterm-279 reproduces the same problem
in my environment.
 For example, this problem happens by following steps.

1. bash whose PS1 is set as described above outputs following escape sequence.
   ESC[01;32m^Buser@host^AESC[01;34m^B ~/a/b/c/d/e/f/g/h/i/j/k/l/m $^AESC[00m^B
2. If screen is scrolled up between '~' and 'm' of the current path,
   the bottom lines including the cursor character are cleared with
   background-color-erase (bce) setting before bce attributes are reset
   by following ESC[00m.
3. The cursor character remains colored.

 I think it is difficult to avoid it because of the behavior of bce.
 If you use mlterm with --term=kterm option(kterm doesn't use bce), this
problem doesn't happen.

 If the problem you found is unique to mlterm, please inform me of it.

> 3. Double- and triple-click select one word/line at a time. However,
> double- and triple-clicking and then dragging the pointer will revert
> back to selecting one character at a time.

 As you mentioned, this behavior is not compatible with xterm, but it is
not easy to solve. It will take some time to think of the way to modify
source code.

> 4. Shift + PgDn (which scrolls down one screen) will output 2~ once it
> reaches the bottom. Shift + some other keys (Home, End, Delete, Left, 
> Up, Down, Right and maybe others) also display stuff, even though they
> don't do anything.

 The attached patch fixes this problem.

> 5. Some programs, such as mutt and nvlc (the ncurses interface for vlc)
> will display black text on black background instead of white on black
> (or whatever else you set fg/bg to). This one also happens with xterm
> and urxvt as far as I know.

 I haven't test mutt and nlvc yet, sorry.

> 6. I personally prefer to use the linux terminfo entry with mlterm, but
> it expects keys F1 to F5 to output something else than mlterm does, and
> there's no way to change it (e.g. via ~/.mlterm/termcap).

 How about following settings in ~/.mlterm/key ?

F1="\x1bOP"
F2="\x1bOQ"
F3="\x1bOR"
F4="\x1bOS"
---
Araki Ken
ara...@us...

[Mlterm-dev-en] A few glitches.

[Andi C. S. <ski...@ya...>]

Hello,

I have downloaded the latest version. I see it still has a few remaining
issues (some of them recently discovered) which need fixing.

1. After some text is output which is too long to fit in one line and
then clearing the screen, the lines which were wraped around can still
be selected with the mouse. Can be tested e.g. by typing random strings
or by issuing ls -l in a directory with some long file names.

2. (May be related) Happens with some fancy shell prompts, if the path
is part of the prompt, or the prompt itself is too long: a coloured
prompt too long to fit in one line will also colour the cursor. May be
tested (with bash) by setting the prompt to:

PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[00m\] '

Sometimes you have to trigger behaviour 1 in order to activate 2.

3. Double- and triple-click select one word/line at a time. However,
double- and triple-clicking and then dragging the pointer will revert
back to selecting one character at a time.

4. Shift + PgDn (which scrolls down one screen) will output 2~ once it
reaches the bottom. Shift + some other keys (Home, End, Delete, Left, 
Up, Down, Right and maybe others) also display stuff, even though they
don't do anything.

5. Some programs, such as mutt and nvlc (the ncurses interface for vlc)
will display black text on black background instead of white on black
(or whatever else you set fg/bg to). This one also happens with xterm
and urxvt as far as I know.

6. I personally prefer to use the linux terminfo entry with mlterm, but
it expects keys F1 to F5 to output something else than mlterm does, and
there's no way to change it (e.g. via ~/.mlterm/termcap).

Regards,
Andi Șerbănescu

[Mlterm-dev-en] mlterm 3.1.3 released

[Araki K. <ara...@us...>]

 Hi,

 This is to announce the release of mlterm version 3.1.3

http://sourceforge.net/projects/mlterm/files/01release/mlterm-3.1.3/mlterm-3.1.3.tar.gz/download

MD5 (mlterm-3.1.3.tar.gz) = 4556b063b027dec614b9e945f56ba773
SHA1 (mlterm-3.1.3.tar.gz) = 7359c0f9a804463154a86797c89bc88189108ebd

Overview of changes from 3.1.2
===============================

ver 3.1.3
* Support OSC 5;0 and OSC 5;1.
* Support CSI ? 8840 h, CSI ? 8840 l and CSI ? 8840 n.
  (see https://docs.google.com/document/d/1Dgq81J0eQEfjq3MR__O7VrbSVnatr9CCqMEITse9psk/edit?pli=1)
* Support CSI SP q partially.
* Support CSI [>4;2 m and CSI [>4;0m partially.
  (Note that sequence from terminal is CSI [<code>;<mod>u, not CSI [27;<mod>;<code>~.)
* Add "ssh_keepalive_interval" option.
* Add "ssh_x11_forwarding" option.
* Add "use_bold_font" option.
* Add "use_local_echo" option and CSI ? 9500 h / CSI ? 9500 l which enable or disable
  local echo mode.
* Merge SF patches:
  #3529392 (Thanks to Ahmed El-Mahmoudy)
  #3529386 (Thanks to Ahmed El-Mahmoudy)
  #3530235 (Thanks to Ahmed El-Mahmoudy)
* Bug fixes:
  #3528838 (Thanks to Thomas Wolff)
  #3528836 (Thanks to Thomas Wolff)
  Fix a bug which wrongly keeps a screen which has failed to open.
  Show characters in the center of cells whose width is larger than the default.
  (Thanks to Andi Cristian Serbanescu)
  Fix a bug which erases scrolled area. (Thanks to Andi Cristian Serbanescu)
  Fix failure of opening pty in startup in MacOS 10.7.
  (Thanks to saitoha san)
--
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] Build problems with recent fribidi.

[Aidan K. <ke...@pa...>]

And, please ignore that, this change is already included in the latest
stable release. Thanks!

 Ar an tríú lá is fiche de mí Iúil, scríobh Aidan Kehoe: 

 > 
 > Hi there,
 > 
 > Bidi support isn’t picked up with recent fribidi. The issue is that mlterm
 > assumes that if fribidi is available, the program fribidi-config will be
 > available; this assumption no longer holds with recent fribidi. The fix is
 > to look for pkg-config support for fribidi too, I’m attaching a patch.
 > 
 > Best,
 > 
 > Aidan

-- 
‘Liston operated so fast that he once accidentally amputated an assistant’s
fingers along with a patient’s leg, […] The patient and the assistant both
died of sepsis, and a spectator reportedly died of shock, resulting in the
only known procedure with a 300% mortality.’ (Atul Gawande, NEJM, 2012)

[Mlterm-dev-en] Build problems with recent fribidi.

[Aidan K. <ke...@pa...>]

Hi there,

Bidi support isn’t picked up with recent fribidi. The issue is that mlterm
assumes that if fribidi is available, the program fribidi-config will be
available; this assumption no longer holds with recent fribidi. The fix is
to look for pkg-config support for fribidi too, I’m attaching a patch.

Best,

Aidan


-- 
‘Liston operated so fast that he once accidentally amputated an assistant’s
fingers along with a patient’s leg, […] The patient and the assistant both
died of sepsis, and a spectator reportedly died of shock, resulting in the
only known procedure with a 300% mortality.’ (Atul Gawande, NEJM, 2012)

Re: [Mlterm-dev-en] Two glitches

[Andi C. S. <ski...@ya...>]

Hello,

Thanks for the update.

> Thanks.
> There was a problem around processing GraphicsExpose
> event.
> I think http://mlterm.sf.net/mlterm-3.1.3pre-20120621.tar.gz
> fixes this problem.
> Please test it.
> 

I think it works. I don't see any ‘skipped’ rows anymore.

> If --enable-fribidi is not specified, bidi module is not built but
> mlterm itself is built with a loader of bidi and indic modules.
> That's why you get (harmless) errors.
> 
> If you want to exclude bidi module completely, do ./configure with
> --disable-dl-ctl option.
>

Ok. So can I safely disable dl-ctl if nothing requires it (freebidi or
ind) then?

Regards,

Andi Șerbănescu

Re: [Mlterm-dev-en] Two glitches

[Araki K. <ara...@us...>]

 Hi,

From: Araki Ken <ara...@us...>
Subject: Re: [Mlterm-dev-en] Two glitches
Date: Thu, 21 Jun 2012 23:00:54 +0900 (JST)
Message-ID: <201...@us...>

>  Does libctl_bidi.so is installed to $prefix/lib/mlterm ?
>  Please try "make;make install" in mlterm-3.1.2/mlterm/libctl (source tree).

 Please ignore this comment.

> > 1. Although I compiled without FreeBiDi support, I still get errors in
> > .mlterm/msg.log such as:
> > 
> > Jun 15 14:16:56[7142] *** ERROR HAPPEND *** BiDi: Could not load.

 If --enable-fribidi is not specified, bidi module is not built but
mlterm itself is built with a loader of bidi and indic modules.
 That's why you get (harmless) errors.

 If you want to exclude bidi module completely, do ./configure with
--disable-dl-ctl option.

 Regards,
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] Two glitches

[Araki K. <ara...@us...>]

 Hi,

From: Andi Cristian Serbanescu <ski...@ya...>
Subject: [Mlterm-dev-en] Two glitches
Date: Fri, 15 Jun 2012 04:46:36 -0700 (PDT)
Message-ID: <133...@we...>

> 1. Although I compiled without FreeBiDi support, I still get errors in
> .mlterm/msg.log such as:
> 
> Jun 15 14:16:56[7142] *** ERROR HAPPEND *** BiDi: Could not load.

 Does libctl_bidi.so is installed to $prefix/lib/mlterm ?
 Please try "make;make install" in mlterm-3.1.2/mlterm/libctl (source tree).

> 2. If some process outputs large quantities of text (e.g. compiling some
> software package) in a mlterm window, then hiding that window behind
> another one (this one can be anything, e.g. firefox) has the result of
> making parts of the output text that were initially below the second
> window appear ‘erased’ after scrolling upwards to the visible part of
> the terminal window.
> 
> This happens regardless of any settings. It seems as though mlterm
> forgot to draw the text in question, but it's rendered visible by
> selecting it. You can try to reproduce it by hiding about half of a
> mlterm window beneath a browser window, then running ./configure && make
> on the mlterm source. You should see it ocasionally skipping about 1–3
> rows of text. You may have to interrupt the process to investigate those
> suspicious lines (i.e. by selecting them), but some may appear towards
> the end.

 Thanks.
 There was a problem around processing GraphicsExpose event.
 I think http://mlterm.sf.net/mlterm-3.1.3pre-20120621.tar.gz fixes this problem.
 Please test it.

 Regards,
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] Two glitches

[Andi C. S. <ski...@ya...>]

And there's one more thing: Shift + Page Down scrolls the text down, but
on reaching the bottom it prints ‘2~’. That means Shift + Page Down
literally outputs ‘^[[6;2~’, compared to Shift + Page Up which doesn't
output anything and only controls terminal scroll.

[Mlterm-dev-en] Two glitches

[Andi C. S. <ski...@ya...>]

Hello,

I've uncovered 2 minor glitches (still in version 3.1.2, although they
have been around for some time):

1. Although I compiled without FreeBiDi support, I still get errors in
.mlterm/msg.log such as:

Jun 15 14:16:56[7142] *** ERROR HAPPEND *** BiDi: Could not load.

2. If some process outputs large quantities of text (e.g. compiling some
software package) in a mlterm window, then hiding that window behind
another one (this one can be anything, e.g. firefox) has the result of
making parts of the output text that were initially below the second
window appear ‘erased’ after scrolling upwards to the visible part of
the terminal window.

This happens regardless of any settings. It seems as though mlterm
forgot to draw the text in question, but it's rendered visible by
selecting it. You can try to reproduce it by hiding about half of a
mlterm window beneath a browser window, then running ./configure && make
on the mlterm source. You should see it ocasionally skipping about 1–3
rows of text. You may have to interrupt the process to investigate those
suspicious lines (i.e. by selecting them), but some may appear towards
the end.

Regards,
Andi Șerbănescu