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