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

Re: [Mlterm-dev-en] How to get "Alt+." key combination working

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

 Hi,

From: Vladimir <vo...@vo...>
Subject: [Mlterm-dev-en] How to get "Alt+." key combination working
Date: Tue, 12 Mar 2013 11:10:24 +0100
Message-ID: <513...@vo...>

> I'd appreciate if anybody would give any tips on how to get Alt+. key
> sequence working (at the moment mlterm doesn't output anything).
> mlterm version: 3.1.8
> distro: Gentoo

 Thanks for your report.
 Alt+. outputs 0xae (REGISTERED SIGN) by defaults, but it didn't
work in UTF-8 encoding.
 The attached patch fixes this problem.

 On the other hand, if you want Alt+. to output "\x1b\x2e" (ESC + .),
please specify "mod_meta_mode" option in ~/.mlterm/main as follows.

~/.mlterm/main
mod_meta_mode = esc

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

[Mlterm-dev-en] How to get "Alt+." key combination working

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

Hello,

I'd appreciate if anybody would give any tips on how to get Alt+. key
sequence working (at the moment mlterm doesn't output anything).
mlterm version: 3.1.8
distro: Gentoo

Thanks in advance,
Vlad.

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

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

 Hi,

From: Araki Ken <ara...@us...>
Subject: Re: [Mlterm-dev-en] A few glitches.
Date: Wed, 30 Jan 2013 20:29:00 +0900 (JST)
Message-ID: <201...@us...>

> > Would it also be possible to compile out those things which presuppose that mlterm can load background images (e.g. options like brightness, contrast, gamma, image path and whatever else may do so) when that feature is disabled, as is the case with SSH?
> 
>  They're compiled for pseudo transparency even if --disable-use-tools is specified.
> 
>  If you want to compile out them, all you have to do is to replace the functions in
> xwindow/x_picture.c and xwindow/xlib/x_imagelib.c by those which return 0 or NULL.
>  Plase try attached dummy x_picture.c and x_imagelib.c.
> 
>  But I don't feel like maintain them in my hg source tree, because I don't want to
> complicate it more.
>  I think there is a merely slight difference between compilation with them and
> without them.
> 
>  [Test in my environment (NetBSD 3.0.1)]
>  Building mlterm by ./configure --disable-dl-ctl --disable-dl-type.
>     x_picture.c/x_imagelib.c VSZ  RSS
>  1) Normal                   508 2000
>  2) Empty                    504 2000

 Though I said earlier as above, --disable-image option which exludes
anything related to images is added to configure script now,
while --enable-sixel option is removed and sixel graphics is enabled by default, 

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

Re: [Mlterm-dev-en] mlterm 3.1.8 released

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

 mlterm version 3.1.8 which I released at 2013-02-23 didn't contain
the symlink files (mlterm/libctl/dexport-fb.map and xwindow/fb/x.c)
for framebuffer support.
 So I replaced the released archive by the new one.

(New archive file)
MD5 (mlterm-3.1.8.tar.gz) = 746bf678bd47c7b5b9d8fdac8207e270
SHA1 (mlterm-3.1.8.tar.gz) = 0754385184e98aad07c61a000ef18244c5879025
--
Araki Ken
ara...@us...

>  This is to announce the release of mlterm version 3.1.8
>   
> http://sourceforge.net/projects/mlterm/files/01release/mlterm-3.1.8/mlterm-3.1.8.tar.gz/download
> 
> MD5 (mlterm-3.1.8.tar.gz) = 58ae1a659855aeba7398e935fa48dca9
> SHA1 (mlterm-3.1.8.tar.gz) = 1d2b6401b3f356f9df9ba0a5e085c5e93d9adc4d
> 
> Overview of changes from 3.1.7
> ===============================
> ver 3.1.8
> * Support framebuffer on FreeBSD. (Experimental)
> * 'key' configuration file accepts Button1 - Button5.
> * Remove "conf_menu_path_1", "conf_menu_path_2", "conf_menu_path_3" and
>   "button3_behavior" options which are integrated to shortcuts.
>   [Migration]
>   (~/.mlterm/main)        (~/.mlterm/key)
>   conf_menu_path_1=... => Control+Button1="menu:..."
>   conf_menu_path_2=... => Control+Button2="menu:..."
>   conf_menu_path_2=... => Control+Button3="menu:..."
>   button3_behavior=... => Button3="exesel:..."
> * Add "set_shortcut" command to configuration protocol.
> * Bug fixes:
>   Fix the bug of DECCRA.
>   Fix the bug which broke input string of "ExecCmd" field of the connection dialog in win32.
>   Fix the bug which didn't redraw a part of full-width characters when window is exposed.
>   Enable to change "vertical_mode" option dynamically in framebuffer.

[Mlterm-dev-en] mlterm 3.1.8 released

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

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

MD5 (mlterm-3.1.8.tar.gz) = 58ae1a659855aeba7398e935fa48dca9
SHA1 (mlterm-3.1.8.tar.gz) = 1d2b6401b3f356f9df9ba0a5e085c5e93d9adc4d

Overview of changes from 3.1.7
===============================
ver 3.1.8
* Support framebuffer on FreeBSD. (Experimental)
* 'key' configuration file accepts Button1 - Button5.
* Remove "conf_menu_path_1", "conf_menu_path_2", "conf_menu_path_3" and
  "button3_behavior" options which are integrated to shortcuts.
  [Migration]
  (~/.mlterm/main)        (~/.mlterm/key)
  conf_menu_path_1=... => Control+Button1="menu:..."
  conf_menu_path_2=... => Control+Button2="menu:..."
  conf_menu_path_2=... => Control+Button3="menu:..."
  button3_behavior=... => Button3="exesel:..."
* Add "set_shortcut" command to configuration protocol.
* Bug fixes:
  Fix the bug of DECCRA.
  Fix the bug which broke input string of "ExecCmd" field of the connection dialog in win32.
  Fix the bug which didn't redraw a part of full-width characters when window is exposed.
  Enable to change "vertical_mode" option dynamically in framebuffer.

--
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, 27 Dec 2012 13:41:00 -0800 (PST)
Message-ID: <135...@we...>

> I've tried compiling the latest (development) version and it fails somewhere. I got the following:
> 
> ../xwindow/xlib/x_imagelib.c:86:14: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
> make[1]: *** [x_imagelib.o] Error 1
> make[1]: Leaving directory `/home/acs/mlterm/xwindow'
> make: *** [all] Error 2

 Thanks. I fixed.

> Would it also be possible to compile out those things which presuppose that mlterm can load background images (e.g. options like brightness, contrast, gamma, image path and whatever else may do so) when that feature is disabled, as is the case with SSH?

 They're compiled for pseudo transparency even if --disable-use-tools is specified.

 If you want to compile out them, all you have to do is to replace the functions in
xwindow/x_picture.c and xwindow/xlib/x_imagelib.c by those which return 0 or NULL.
 Plase try attached dummy x_picture.c and x_imagelib.c.

 But I don't feel like maintain them in my hg source tree, because I don't want to
complicate it more.
 I think there is a merely slight difference between compilation with them and
without them.

 [Test in my environment (NetBSD 3.0.1)]
 Building mlterm by ./configure --disable-dl-ctl --disable-dl-type.
    x_picture.c/x_imagelib.c VSZ  RSS
 1) Normal                   508 2000
 2) Empty                    504 2000

> > How about "conf_men_path_1" "conf_men_path_2" and "conf_men_path_3" options ?
> 
> Yes, I know about them, but the other way would be more flexible. Treating the mouse buttons as keys are would allow any button/modifier combination to be (re)bound to anything the keybindings currently support (or to be easily disabled).
> 
> My idea is to add an option to run any command string, which would implement the current behaviour by default. This would also prevent having disparate options for control plus all buttons, for button 3 alone and for the menu path.

 It looks good idea.
 Now mlterm hg head accepts Button1 - Button5 keys in ~/.mlterm/key as follows.

Control+Button1="menu:mlconfig"
Button4="\x1bOA"
Button5="\x1bOB"

 And shortcut settings are changeable dynamically as follows.

 $ mlcc exec set_shortcut Button3=\"proto:encoding=eucjp\"

 (See man page and etc/key in detail.)

> And then there's also the issue of artefacts. Opening http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt with e.g. lynx and scrolling past the Ethiopian text would leave some of those behind.

 The cause of this problem is the same as that of U+2592.
 www.unicode.org/Public/UNIDATA/EastAsianWidth.txt defines Ethiopian characters
as narrow width, but GNU Unifont contains them as full width(16x16).
 But I don't plan to add glitches for GNU Unifont anymore.

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

[Mlterm-dev-en] mlterm 3.1.7 released

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

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

MD5 (mlterm-3.1.7.tar.gz) = 97396cd84cbef20f5fd4dae37487cb4a
SHA1 (mlterm-3.1.7.tar.gz) = 27e6d9c61b98fb08fba2f777688da78d41508389
  
Overview of changes from 3.1.6
===============================
ver 3.1.7
* Support not only bmp formats but also other image formats by mlimgloader
  (which requires gdk-pixbuf or GDI+) in win32.
* "contrast", "gamma" and "brightness" options are available in win32.
* Support CSI 22 0..2 t and CSI 23 0..2 t.
* Support DCS ... { ... ST. (DECDLD)
  (http://github.com/saitoha/vim-powerline/tree/drcs works!)
* Assign U+10XXYY like drcsterm to DRCS (ESC ( SP XX YY)
  (0x40 <= XX <= 0x7e, 0x20 <= YY <= 0x7f)
  (See http://github.com/saitoha/drcsterm)
* Remove "title" from configuration protocol.
* Support alpha values of icon files if mlterm is built without
  --with-imagelib=gdk-pixbuf option.
* Support UTF8 text for setting the window title by OSC 0 or OSC 2 in win32.
* Add --disable-use-tools option (which disables external tools) to configure.
* Support alpha mask of sixel graphics.
* Support uim and kbd plugin in framebuffer.
* Bug fixes:
  Fix the bug of "button3_behavior" option rejecting "mlclient ..." command.
  Fix the incorrect parsing of font names which contain digit characters like
  "Courier 10 Pitch" which was regarded as 10-point size "Courier" font.
  Adjust the pty size to the screen size in creating a new pty by Ctrl+F2 etc
  in framebuffer.
  Revive "contrast", "gamma" and "brightness" options of mlterm built without
  --with-imagelib option in Linux.
  Fix segfault in starting mlterm with --pic option in framebuffer.
  Fix the malfunction of cursor keys in mlcc in cygwin. (Thanks to saitoha san)
  Fix the bug of saving or restoring cursor in OSC ? 1047 h or OSC ? 1047 l.
  Exit mlcc to avoid segfault if OSC 5380 doesn't return anything.
  Fix the bug of unloading fonts which are still used in framebuffer.
--
Araki Ken
ara...@us...

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

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

Hello,

I've tried compiling the latest (development) version and it fails somewhere. I got the following:

../xwindow/xlib/x_imagelib.c:86:14: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
make[1]: *** [x_imagelib.o] Error 1
make[1]: Leaving directory `/home/acs/mlterm/xwindow'
make: *** [all] Error 2

> Sorry, --disable-use-tools didn't work correctly by the bug of configure script.
> I fixed it, and pushed the fixes to hg head.

Thanks, it works now. Would it also be possible to compile out those things which presuppose that mlterm can load background images (e.g. options like brightness, contrast, gamma, image path and whatever else may do so) when that feature is disabled, as is the case with SSH?


> How about "conf_men_path_1" "conf_men_path_2" and "conf_men_path_3" options ?

Yes, I know about them, but the other way would be more flexible. Treating the mouse buttons as keys are would allow any button/modifier combination to be (re)bound to anything the keybindings currently support (or to be easily disabled).

My idea is to add an option to run any command string, which would implement the current behaviour by default. This would also prevent having disparate options for control plus all buttons, for button 3 alone and for the menu path.

> The glyph of U+2592 of GNU Unifont is full width, while mlterm
> (unless -ac 2 option is specified) and finch deal it as half width.
> It is impossible to fix this problem completely, but I pushed a
> few fixes which improve the situation to hg head.

> (Indeed urxvt seems to show it correctly, but I think that urxvt
> redraws characters more than necessary in using GNU Unifont and
> that it results in showing correctly by chance.)

Impacting performance would be indeed bad, but it displays correctly most of the time now (it only seems to be the case for core fonts, though). The only way to get rid of it would probably be to modify the font (is there any reason why block characters should be 16 pixels wide, anyway?).

And then there's also the issue of artefacts. Opening http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt with e.g. lynx and scrolling past the Ethiopian text would leave some of those behind.

Regards,
Andi Șerbănescu

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: Sun, 16 Dec 2012 07:13:53 -0800 (PST)
Message-ID: <135...@we...>

> However, mlimgloader still builds, even though I didn't specify it (it seems to append itself to whatever parameter I give to --with-tools, including an empty string).

 Sorry, --disable-use-tools didn't work correctly by the bug of
configure script.
 I fixed it, and pushed the fixes to hg head.

> By the way, could the mouse actions (menu and configurator) not be made hard-coded, but configurable as the keys are (possibly renaming the key file to something like bindings to reflect the change)?

 How about "conf_men_path_1" "conf_men_path_2" and "conf_men_path_3" options ?

> It seems to be caused by mlterm displaying those characters in a 16×8 cell, although they're actually 16×16 in size, thus sometimes displaying over the next character and sometimes pushing it to the right.
> 
> Running mlterm with --logseq itself seems to trigger the former behaviour over the latter. See the two window dumps for comparison (display them with "xz -cd FILENAME | xwud").
> 
> Of course, it only happens with GNU Unifont, which has characters of both widths. I have set termtype to linux-m, since it uses the font's box drawing characters instead of those drawn by mlterm itself.

 The glyph of U+2592 of GNU Unifont is full width, while mlterm
(unless -ac 2 option is specified) and finch deal it as half width.
 It is impossible to fix this problem completely, but I pushed a
few fixes which improve the situation to hg head.

 (Indeed urxvt seems to show it correctly, but I think that urxvt
 redraws characters more than necessary in using GNU Unifont and
 that it results in showing correctly by chance.)

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

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

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

Hello,

> Oh, sorry. I understand.

> But do they have something harmful ?
> At least, I made a patch to add "--disable-use-tools" configure option

> which disable them.
> (I haven't merged it to hg head yet)

They're not harmful, but they seem a little superfluous in case you don't want anything else built in.

However, mlimgloader still builds, even though I didn't specify it (it seems to append itself to whatever parameter I give to --with-tools, including an empty string).

By the way, could the mouse actions (menu and configurator) not be made hard-coded, but configurable as the keys are (possibly renaming the key file to something like bindings to reflect the change)?

> I tried finch, but I couldn't reproduce this problem.

> (U+2592 shows correctly.)
> Will you start mlterm with --logseq option, use finch until the problem happens
> and send me a ~/.mlterm/*.log file ?


It seems to be caused by mlterm displaying those characters in a 16×8 cell, although they're actually 16×16 in size, thus sometimes displaying over the next character and sometimes pushing it to the right.


Running mlterm with --logseq itself seems to trigger the former behaviour over the latter. See the two window dumps for comparison (display them with "xz -cd FILENAME | xwud").

Of course, it only happens with GNU Unifont, which has characters of both widths. I have set termtype to linux-m, since it uses the font's box drawing characters instead of those drawn by mlterm itself.


Regards,
Andi Șerbănescu

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: Sat, 8 Dec 2012 09:48:06 -0800 (PST)
Message-ID: <135...@we...>

> >  If you specify --with-imagelib=gdk-pixbuf, mlimgloader is
> > built in mlterm.
> >  But it is not possible to build the other configuration
> > programs like mlconfig
> > into mlterm now.
> > 
> >  Most of configuration functions should be rewritten from
> > scratch to build them
> > into mlterm.
> 
> I'm sorry, I didn't mean integrating them into mlterm itself, but rather disabling the parts which try to access those features (hence the analogy with disable-dl-ctl) when mlterm is built without support for menus or the image loader.

 Oh, sorry. I understand.
 But do they have something harmful ?

 At least, I made a patch to add "--disable-use-tools" configure option
which disable them.
 (I haven't merged it to hg head yet)

> I have also encountered a weird glitch involving the Unifont typeface (it's a monospace bitmap font which also has a ttf variant, although I only use the pcf version). It concerns the medium shade block character (U+2592) and the program finch (console version of pidgin), which uses it as part of a scrollbar.
> 
> Scrolling the contact list will replace parts of the window border with such glyphs. Having a monochrome TERM setting (such as vt100 or linux-m) will only make things worse, as all the character cells adjacent to the scrollbar will all be replaced with medium shade glyphs.
> 
> 
> Since I don't know any other program which behaves this way, finch is the only known means to reproduce it. The reason I'm telling you is that it does not happen with urxvt; it only happens with xterm and mlterm. Can you try looking into this? (By the way, any luck with the BCE cursor thing?)

 I tried finch, but I couldn't reproduce this problem.
 (U+2592 shows correctly.)

 Will you start mlterm with --logseq option, use finch until the problem happens
and send me a ~/.mlterm/*.log file ?
---
Araki Ken
ara...@us...

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

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

Hello,

>  If you specify --with-imagelib=gdk-pixbuf, mlimgloader is
> built in mlterm.
>  But it is not possible to build the other configuration
> programs like mlconfig
> into mlterm now.
> 
>  Most of configuration functions should be rewritten from
> scratch to build them
> into mlterm.

I'm sorry, I didn't mean integrating them into mlterm itself, but rather disabling the parts which try to access those features (hence the analogy with disable-dl-ctl) when mlterm is built without support for menus or the image loader.


I have also encountered a weird glitch involving the Unifont typeface (it's a monospace bitmap font which also has a ttf variant, although I only use the pcf version). It concerns the medium shade block character (U+2592) and the program finch (console version of pidgin), which uses it as part of a scrollbar.

Scrolling the contact list will replace parts of the window border with such glyphs. Having a monochrome TERM setting (such as vt100 or linux-m) will only make things worse, as all the character cells adjacent to the scrollbar will all be replaced with medium shade glyphs.


Since I don't know any other program which behaves this way, finch is the only known means to reproduce it. The reason I'm telling you is that it does not happen with urxvt; it only happens with xterm and mlterm. Can you try looking into this? (By the way, any luck with the BCE cursor thing?)

Regards,
Andi Șerbănescu

[Mlterm-dev-en] mlterm 3.1.6 released

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

 Hi,
  
 This is to announce the release of mlterm version 3.1.6

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

MD5 (mlterm-3.1.6.tar.gz) = cb3d2dc8a04255a88f9cc619bd119a23
SHA1 (mlterm-3.1.6.tar.gz) = 59ece5e3ae0dc618669052e42a759dbd23e771e7

Overview of changes from 3.1.5
===============================  
ver 3.1.6
* Support ":[Percentage]" format for font-fb.
  (e.g. ISO8859_1=/../font.pcf:100)
* Support gzipped pcf fonts in framebuffer.
* Support 3 byte rgb color sequence.
  (<ESC>[38;2;<r>;<g>;<b>m and <ESC>[48;2;<r>;<g>;<b>m)
* Support DECCRA(<ESC>[...$v) and DECERA(<ESC>[...$z).
* Add --altbuf / "use_alt_buffer" option which is equivalent to
  "titeInhibit" of xterm.
* Add --colors / "use_ansi_colors" option which is equivalent to
  "colorMode" of xterm.
* Add --exitbs / "exit_backscroll_by_pty" option.
* -Y option converts unicode line drawing characters (U+2500 etc) to dec
  special ones in order to show them correctly with a unicode font which
  contains double-width glyphs or no glyphs for line characters.
* Update unicode property table (generated from UnicodeData.txt and
  EastAsianWidth.txt) to version 6.2.0.
* "blink_cursor" option is available for libvte.
* Remove "add_picture" and "remove_picture" commands from configuration
  protocol, and add "show_picture" command to it.
* Change key sequences in term_type=mlterm
  (application cursor key mode is off)
  XK_HOME: \x1bOH -> \x1b[H   XK_END : \x1bOF -> \x1b[F
* Change key seuqences in term_type=rxvt.
  (application cursor key mode is off)
  XK_HOME: \x1b[7~ -> \x1b[H  XK_END : \x1b[8~ -> \x1b[F
  (application cursor key mode is on)
  XK_HOME: \x1bOH -> \x1b[7~  XK_END : \x1bOF -> \x1b[8~
* Bug fixes:
  Fix the bug of showing incorrect glyphs of large fonts like unifont.pcf.
  Fix the infinite loop in the failure of executing the command specified with -e option.
  Fix the compilation error in linking gdk-pixbuf-2.0. (SF topic #6234829)
  (Thanks to Lotus Shih and rabin_y)
  Fix the bug of incorrect input of 'A' - 'Z' keys in win32.
  Fix the memory leak of scrollbar views.
--
Araki Ken
ara...@us...

------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Mlterm-dev-en mailing list
Mlt...@li...
https://lists.sourceforge.net/lists/listinfo/mlterm-dev-en

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: Fri, 23 Nov 2012 11:32:30 -0800 (PST)
Message-ID: <135...@we...>

> > Do you define hl_white in ~/.mlterm/color ?
> > In my environment "mlterm -fg hl_white" works as expected
> > if hl_white
> > is defined in ~/.mlterm/color.
> 
> I did. It seems to work only for values other than rgb:ff/ff/ff.

 Oh, sorry. I fixed it.

> >  All thing mlterm does now is to output an error message.
> >  What do you think should be done about it ?
> 
> I was thinking about something analogous to --disable-dl-ctl.

 If you specify --with-imagelib=gdk-pixbuf, mlimgloader is built in mlterm.
 But it is not possible to build the other configuration programs like mlconfig
into mlterm now.

 Most of configuration functions should be rewritten from scratch to build them
into mlterm.

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

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

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

Hello,

> Do you define hl_white in ~/.mlterm/color ?
> In my environment "mlterm -fg hl_white" works as expected
> if hl_white
> is defined in ~/.mlterm/color.

I did. It seems to work only for values other than rgb:ff/ff/ff.

>  All thing mlterm does now is to output an error message.
>  What do you think should be done about it ?

I was thinking about something analogous to --disable-dl-ctl.

Regards,
Andi Șerbănescu

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, 22 Nov 2012 14:26:52 -0800 (PST)
Message-ID: <135...@we...>

> It works, but with one exception: it still leaves hl_white unselectable.

 Do you define hl_white in ~/.mlterm/color ?
 In my environment "mlterm -fg hl_white" works as expected if hl_white
is defined in ~/.mlterm/color.

> Also, can something be done about mlterm trying to load (and fail) stuff
> the user has opted to compile out (graphical menu, configurator, image loader etc.)?

 All thing mlterm does now is to output an error message.
 What do you think should be done about it ?

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

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

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

Hello,

Thank you for the patch. It works, but with one exception: it still leaves hl_white unselectable.

Also, can something be done about mlterm trying to load (and fail) stuff the user has opted to compile out (graphical menu, configurator, image loader etc.)?

Regards,
Andi Șerbănescu

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, 21 Nov 2012 12:50:38 -0800 (PST)
Message-ID: <135...@we...>

> A bug did actually creep in: colour keywords set in ~/.mlterm/main (i.e. for bg, fg, bd and ul) do not take the values specified in ~/.mlterm/color but the built-in defaults (and if the keyword is prefixed with hl_ then they're all black).

 Thanks. I fixed.

> >  I plan to change these behaviors in the next release.
> >  (see doc/en/ReleaseNote)
> > 
> >  Originally kh and @7 of termcap should be applied in the
> > application cursor key mode(ESC[?1h), but kh and @7 of
> > mlterm (3.1.4 or before) termcap works in the normal mode.
> >  So I think kh and @7 of mlterm termcap should work in
> > the application cursor key mode instead of the normal mode.
> >  As a result, the sequence generated by Home or End key
> > in the normal mode is always \E[H or \E[F (same as xterm)
> > in the current hg head.
> > 
> >  This change breaks the backward compatibility, so
> > I might think of the way to keep the backward compatibility
> > if necessary.
> 
> Oh, sorry about that. But aren't the other ones (backspace, function keys etc.) modified only for normal mode (actually, I think there's no application mode for them)?

 The other ones are always modified.

> >  This hebavior is intended.
> >  I implemented it from the beginning because of my
> > preference.
> 
> Then could you please consider adding an option for it to work the other way, too?

 I pushed the fixes to hg head.
 Please rebuilt it and start mlterm with --exitbs option or adding
exit_backscroll_by_pty=true to ~/.mlterm/main.

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

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

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

Hello,

A bug did actually creep in: colour keywords set in ~/.mlterm/main (i.e. for bg, fg, bd and ul) do not take the values specified in ~/.mlterm/color but the built-in defaults (and if the keyword is prefixed with hl_ then they're all black).

>  I plan to change these behaviors in the next release.
>  (see doc/en/ReleaseNote)
> 
>  Originally kh and @7 of termcap should be applied in the
> application cursor key mode(ESC[?1h), but kh and @7 of
> mlterm (3.1.4 or before) termcap works in the normal mode.
>  So I think kh and @7 of mlterm termcap should work in
> the application cursor key mode instead of the normal mode.
>  As a result, the sequence generated by Home or End key
> in the normal mode is always \E[H or \E[F (same as xterm)
> in the current hg head.
> 
>  This change breaks the backward compatibility, so
> I might think of the way to keep the backward compatibility
> if necessary.

Oh, sorry about that. But aren't the other ones (backspace, function keys etc.) modified only for normal mode (actually, I think there's no application mode for them)?

>  This hebavior is intended.
>  I implemented it from the beginning because of my
> preference.

Then could you please consider adding an option for it to work the other way, too?

Regards,
Andi Șerbănescu

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: Sun, 18 Nov 2012 07:26:41 -0800 (PST)
Message-ID: <135...@we...>

> However, I have noticed that the development version does not obey
> the kh and @7 fields in the termcap file (although it does obey the key file).
> Instead, Home and End always output \E[H and \E[F. Does this happen to you too?

 I plan to change these behaviors in the next release.
 (see doc/en/ReleaseNote)

 Originally kh and @7 of termcap should be applied in the
application cursor key mode(ESC[?1h), but kh and @7 of
mlterm (3.1.4 or before) termcap works in the normal mode.
 So I think kh and @7 of mlterm termcap should work in
the application cursor key mode instead of the normal mode.
 As a result, the sequence generated by Home or End key
in the normal mode is always \E[H or \E[F (same as xterm)
in the current hg head.

 This change breaks the backward compatibility, so
I might think of the way to keep the backward compatibility
if necessary.

> Also something I noticed: the default behaviour of back-scrolling when the terminal is outputting is to scroll parallel to the output (the alternative is to disable scrolling completely). Is this intended? Other terminal emulators would exit back-scrolling mode instead and hit the bottom, just as they would do on keypress.

 This hebavior is intended.
 I implemented it from the beginning because of my preference.

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

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

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

Hello,

Thank you for the update; I have built it and it works well. However, I have noticed that the development version does not obey the kh and @7 fields in the termcap file (although it does obey the key file). Instead, Home and End always output \E[H and \E[F. Does this happen to you too?

Also something I noticed: the default behaviour of back-scrolling when the terminal is outputting is to scroll parallel to the output (the alternative is to disable scrolling completely). Is this intended? Other terminal emulators would exit back-scrolling mode instead and hit the bottom, just as they would do on keypress.

Regards,
Andi Șerbănescu

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: Fri, 9 Nov 2012 15:06:11 -0800 (PST)
Message-ID: <135...@we...>

> 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.

 I added a option to ignore color sequences to hg head.
 Please start mlterm with --colors=false option.
 (Or add use_ansi_colors=false to ~/.mlterm/main.)

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

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

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

Thanks for the explanation and, of course, for your help!

Regards,
Vladimir.

On Mon, 2012-11-12 at 20:49 +0900, Araki Ken wrote:
>  Hi,
> 
> From: Vladimir Elisseev <vo...@vo...>
> Subject: Re: [Mlterm-dev-en] few question regarding mlterm initial configuration
> Date: Sun, 11 Nov 2012 12:30:08 +0100
> Message-ID: <135...@vo....home>
> 
> > Since I'm using Xft I thought that this option is on by default. At
> > least that's what man says:
> >        -Y, --decsp(=bool)
> >               Use  dynamically composed line drawing character set.  This overrides DEC_SPECIAL in "font" configuration file.  The default is false.  This
> >               option is automatically turned on when Xft or cairo is used.
> > 
> > Nevertheless, with -Y option all the lines are displayed correctly, thanks! Do I still your patch applied?
> 
>  My explanation is not enough, sorry.
> 
>  The patch I posted changes the behavior of -Y option (to avoid to add
> a new option), so it is necessary to specify -Y in starting mlterm after
> the patch is applied.
> (The manual page has been already changed in hg head.)
> 
>  This problem happens as follows.
> 
>   Console application -> (0x71[HORIZONTAL LINE] of DEC SPECIAL)
>   -> tmux -> (U+2500 of Unicode which tmux converts 0x71 to)
>   -> mlterm
>   -> If the glyph for U+2500 doesn't exist in the unicode font mlterm
>      loads, the line drawing character isn't shown correctly.
> 
>  Now if you specify -Y option explicitly, unicode line drawing characters
> (U+2500 etc) are converted to line drawing characters of DEC Special
> characters, not only drawn by dynamically composed glyphs.
> 
>   Console application -> (0x71[HORIZONTAL LINE] of DEC SPECIAL)
>   -> tmux -> (U+2500 of Unicode which tmux converts 0x71 to)
>   -> mlterm -Y -> (0x71 of DEC SPECIAL which mlterm converts U+2500 to)
>   -> The line drawing character is correctly shown.
> 
> ---
> 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: Re: [Mlterm-dev-en] few question regarding mlterm initial configuration
Date: Sun, 11 Nov 2012 12:30:08 +0100
Message-ID: <135...@vo....home>

> Since I'm using Xft I thought that this option is on by default. At
> least that's what man says:
>        -Y, --decsp(=bool)
>               Use  dynamically composed line drawing character set.  This overrides DEC_SPECIAL in "font" configuration file.  The default is false.  This
>               option is automatically turned on when Xft or cairo is used.
> 
> Nevertheless, with -Y option all the lines are displayed correctly, thanks! Do I still your patch applied?

 My explanation is not enough, sorry.

 The patch I posted changes the behavior of -Y option (to avoid to add
a new option), so it is necessary to specify -Y in starting mlterm after
the patch is applied.
(The manual page has been already changed in hg head.)

 This problem happens as follows.

  Console application -> (0x71[HORIZONTAL LINE] of DEC SPECIAL)
  -> tmux -> (U+2500 of Unicode which tmux converts 0x71 to)
  -> mlterm
  -> If the glyph for U+2500 doesn't exist in the unicode font mlterm
     loads, the line drawing character isn't shown correctly.

 Now if you specify -Y option explicitly, unicode line drawing characters
(U+2500 etc) are converted to line drawing characters of DEC Special
characters, not only drawn by dynamically composed glyphs.

  Console application -> (0x71[HORIZONTAL LINE] of DEC SPECIAL)
  -> tmux -> (U+2500 of Unicode which tmux converts 0x71 to)
  -> mlterm -Y -> (0x71 of DEC SPECIAL which mlterm converts U+2500 to)
  -> The line drawing character is correctly shown.

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

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

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

Since I'm using Xft I thought that this option is on by default. At
least that's what man says:
       -Y, --decsp(=bool)
              Use  dynamically composed line drawing character set.  This overrides DEC_SPECIAL in "font" configuration file.  The default is false.  This
              option is automatically turned on when Xft or cairo is used.

Nevertheless, with -Y option all the lines are displayed correctly, thanks! Do I still your patch applied?

Regards,
Vlad.

On Sun, 2012-11-11 at 17:26 +0900, Araki Ken wrote:
>  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...